Jump to content


Game Maker and HTML5


  • This topic is locked This topic is locked
42 replies to this topic

#1

  • Guests

Posted 27 February 2011 - 03:04 PM

Blog posting

This topic is to allow further discussion of my blog posting about the latest development of Game Maker. Please have a read of the posting then feel free to post constructive questions. I will NOT be answering anything on how this will be commercialised - we don't know yet, so don't ask. But if you have any other questions about it.. I'll try and answer. However be aware I obviously can't answer everything for other commercial reasons. But I'll do my best.

Please keep it "constructive", or your post will be nuked from orbit.

Mike

#2 masterm

masterm

    GMC Member

  • GMC Member
  • 1070 posts

Posted 27 February 2011 - 03:48 PM

All i can say is great work mike and team!
  • 0

#3 conman124

conman124

    The Almighty!

  • New Member
  • 282 posts

Posted 27 February 2011 - 04:09 PM

After briefly reading up on HTML5 and seeing a few example games created with it, I am quite excited for this new technology! My question is, how much functionality will we have to give up?
  • 0

#4 YellowAfterlife

YellowAfterlife

    GMC Member

  • Global Moderators
  • 4001 posts
  • Version:GM:Studio

Posted 27 February 2011 - 04:12 PM

I have several (hopefully logical) questions:
1. What is going to be done to keep runner secure? I mean - no matter how much the code is obfuscated, it still can be used, and first public GM HTML5 game will release runner source to public. And then... Arr!
2. Will the file i\o work for html5, and, importantly, will the object_event_add\execute_string\execute_file functions work? Your blog says that GML will be converted, so to parse strings, code converter will have to be packed into a runner too?
3. Blog says that there are issues with tilting images. But doesn't 'pixel-per-pixel' work fast enough in javascript?
  • 1

#5 round

round

    GMC Member

  • GMC Member
  • 167 posts

Posted 27 February 2011 - 04:47 PM

Hello, Mike.Dailly,

I have read your blog post. I am very glad that you only needed less than two weeks to complete the HTML 5 plug-in. You are a very smart and professional programmer...yes!!!

In your blog post:

"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. "

It is very very good news. Many GM users expect Game Maker to become a traditional compiler or a just-in-time compiler for a long time. If Windows version of Game Maker becomes a compiler, large GM games will also be run quickly...SURE! Then many many professional game developers and game studios will switch to use Game Maker to product games.

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

Edited by round, 27 February 2011 - 04:48 PM.

  • 3

#6

  • Guests

Posted 27 February 2011 - 04:49 PM

I'm not sure how much you'll have to give up yet. In terms of visuals, it depends on the use of Canvas or WebGL. But if you design a game knowing these limits, you'll be surprised just how little it effects you. Scaling and rotating still work, so for normal 2D games, you should be fine. The only "biggie" so far is the lack of tinting. And if you know that at the start, there are usually other ways to do the same effect.

In terms of security.... Like I said on the blog; we know its an issue, and will see how much can be done to help protect content. But at the end of the day, to make games run in HTML5 and a browser, you have to let the platform run the code. We do have some ideas, but we'll have to wait and see if they are enough... The only good thing, is that each game will be obfuscated differently, so it'll be harder to track things down... but if you copy it wholesale... yes, its still easy to copy.

That said... you're probably not going to manage to sell games on the web, or at least single player games. Of course if your doing a multi-player game, then they can't steal the server side code anyway - and that's where the real value is to be honest.

File I/O is obviously limited. It's on the web. But there is a "local storage" concept, so certain things will work. File IO may well be simulated via WAD files or something, and downloaded off the web. So I can see most of it still being possible.

String execute. Well... in commercial games, you never get this functionality, and they work pretty well. My first guess is no. You won't be allowed to use "execute_string()". It's a pretty evil bit of code, even though you can do some incredibly cool things with it. That said... where there's a will there's a way, but I've yet to see a bit of code executed that couldn't be done statically anyway. Actually... I'll take that back. I know of ONE bit of code you need it for, but for games... it's not a huge issue.

No. javascript Pixel-per-pixel tinting isn't fast enough. (at least not yet)

#7 Dark Matter

Dark Matter

    RPG Expert

  • GMC Member
  • 3196 posts
  • Version:GM:Studio

Posted 27 February 2011 - 05:20 PM

I was pretty sure Safari had the best (or very close to the best) HTML5 (and CSS3) support. But you say it's rubbish?
  • 4

#8 HaRRiKiRi

HaRRiKiRi

    GMC Member

  • GMC Member
  • 1364 posts

Posted 27 February 2011 - 05:37 PM

I was pretty sure Safari had the best (or very close to the best) HTML5 (and CSS3) support. But you say it's rubbish?

There is difference between support and speed. Maybe it supports more of the specification, but it doesn't run it fast enought for solid 60fps.
  • 3

#9 Dark Matter

Dark Matter

    RPG Expert

  • GMC Member
  • 3196 posts
  • Version:GM:Studio

Posted 27 February 2011 - 05:43 PM


I was pretty sure Safari had the best (or very close to the best) HTML5 (and CSS3) support. But you say it's rubbish?

There is difference between support and speed. Maybe it supports more of the specification, but it doesn't run it fast enought for solid 60fps.

Possibly, though you'd imagine one with the best support would also have the best speed. Also, Chrome is said to be good, though it runs on WebKit, just like Safari, so you'd think they'd be similar too.
  • 0

#10 paul23

paul23

    GMC Member

  • Global Moderators
  • 3857 posts
  • Version:GM:Studio

Posted 27 February 2011 - 05:58 PM

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

As for more technical:
Well execute_string(..) isn't ever very usefull. However other dynamic things are: object_event-adding allows you to execute code from a different source file than the main executable (allows for updating part of the game instead of the whole game). - In map loaders I quite of ten use "variable_local_set" (after checking that the variable name is in a string of "allowed variables") further more "variable_*_array_set" is *currently* the only way to pass arrays around to and from scripts - or similate the idea of pass-by-reference/pointer.
Though as you said it's not often needed, and I only use it to create file-parsers. - And with the limited amount of file handling (would external resource loading work in some way?) as well as the fact that people don't expect full-scale games with mods & mappacks to play through a browser, this won't be a main problem.
  • 0

#11 rwkay

rwkay

    YoYo Games CTO

  • YoYo Games Staff
  • 2357 posts
  • Version:Unknown

Posted 27 February 2011 - 05:59 PM

...

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


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.
  • 1

#12 Cakefish

Cakefish

    I Shot The Sheriff

  • GMC Member
  • 1468 posts
  • Version:GM:Studio

Posted 27 February 2011 - 06:06 PM

It is very good news! But may I ask what it might be used for? I'm assuming it means GM games can be played in the browser, is this right? Are there other possible uses for HTML5 GM games as well?


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




This made my day :)
  • 0

#13 Dark Matter

Dark Matter

    RPG Expert

  • GMC Member
  • 3196 posts
  • Version:GM:Studio

Posted 27 February 2011 - 06:24 PM

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

I thought D&D already had their own GML functions?
  • 0

#14

  • Guests

Posted 27 February 2011 - 06:45 PM

The do, but they have an entirely separate path, and one that's really slow to boot. If you simply compile the D&D into GML, then it's one single path for it all to follow. It also means folk can learn GML by looking at the "compiled" code which is an added bonus.

#15 Desert Dog

Desert Dog

    GMC Member

  • GMC Elder
  • 6409 posts
  • Version:Unknown

Posted 27 February 2011 - 06:50 PM

Very, very, very exciting. Great blog post.

I don't really know anything about the technical side of things with html5, but there will be restrictions in what we can use? I.e. if we want to make an html5 version, we wouldn't want to use 3d, or surfaces, or...?
  • 0

#16 Dark Matter

Dark Matter

    RPG Expert

  • GMC Member
  • 3196 posts
  • Version:GM:Studio

Posted 27 February 2011 - 06:54 PM

The do, but they have an entirely separate path, and one that's really slow to boot. If you simply compile the D&D into GML, then it's one single path for it all to follow. It also means folk can learn GML by looking at the "compiled" code which is an added bonus.

Ah, I see. Will the HTML5 games run in an actual web page then, and not in a separate window? That'd be really good :D
  • 0

#17 Lewis Cross

Lewis Cross

    Artist

  • GMC Member
  • 1003 posts
  • Version:GM:Studio

Posted 27 February 2011 - 08:40 PM

Oohh, this is very good, Construct is going HTML5 too, and that'a also nice. I'm a happy person.
  • 1

#18 Smarty

Smarty

    GMC Member

  • GMC Elder
  • 7470 posts
  • Version:GM:Studio

Posted 27 February 2011 - 09:37 PM

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.
  • 1

#19 NakedPaulToast

NakedPaulToast

    GM Studio/Mac/Win

  • GMC Member
  • 8290 posts
  • Version:GM:Studio

Posted 27 February 2011 - 09:45 PM

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?
  • 0

#20 Rusky

Rusky

    GMC Member

  • GMC Member
  • 2492 posts

Posted 27 February 2011 - 09:45 PM

HTML5 is an interesting target for web games. Flash games have been popular forever and when HTML5 is supported well enough it may be a viable alternative. Decompilation shouldn't be a problem either, as it's just as possible with Flash...

However, much more interesting is the fact that expansion into JavaScript has given you insight into compilation in general. GM is a lot slower than it needs to be and all the optimizations to the runner you have made and would like to make, along with a faster interpreter/compiler will definitely help that.

The biggest thing here, I think, is how to deal with the differences between the growing range of platforms you can support. If you can make GM a good tool for desktop, mobile and web games you'll have something really useful.

---

On a more strict GML- with a good parser (which I would guess already exists as part of the runner) the syntax of GML should have virtually no impact on its conversion to other languages, so long as the semantics are similar as well. Differences like = vs ==, semicolons, etc. only matter if you're naively trying to find-and-replace your way to a different language.

GM already knows what = means, so once it's stored in its own format as a token, opcode, etc. rather than as a text string it doesn't matter how the user typed it. You could even convert it to Lisp syntax if you wanted, just by an operation on the syntax tree.

Edited by Rusky, 27 February 2011 - 09:51 PM.

  • 0

#21 Dark Matter

Dark Matter

    RPG Expert

  • GMC Member
  • 3196 posts
  • Version:GM:Studio

Posted 27 February 2011 - 09:49 PM

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.
  • 0

#22 Krisando

Krisando

    GMC Member

  • New Member
  • 1351 posts

Posted 27 February 2011 - 09:57 PM

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.
  • 0

#23 GameGeisha

GameGeisha

    GameGeisha

  • GMC Member
  • 4373 posts
  • Version:GM:Studio

Posted 27 February 2011 - 09:58 PM

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
  • 0

#24 RhysAndrews

RhysAndrews

    Game Designer

  • GMC Member
  • 2003 posts
  • Version:GM8

Posted 27 February 2011 - 10:01 PM

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
  • 0

#25 Dark Matter

Dark Matter

    RPG Expert

  • GMC Member
  • 3196 posts
  • Version:GM:Studio

Posted 27 February 2011 - 10:01 PM

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.
  • 3

#26 amd42

amd42

    GMC Member

  • GMC Member
  • 269 posts
  • Version:GM8

Posted 27 February 2011 - 10:10 PM

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!


...
  • 1

#27 Desert Dog

Desert Dog

    GMC Member

  • GMC Elder
  • 6409 posts
  • Version:Unknown

Posted 27 February 2011 - 11:03 PM

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.
  • 0

#28

  • Guests

Posted 27 February 2011 - 11:31 PM

Right first. Quite ranting. This is not a normal GM forum, I will not stand for tangents are flame wars. I have better things to do that wade through the crap. Keep it civil or keep out.

Now that that's delt with... FLASH. Yes, we realised this as well, particularly as the new flash will be Javascript based. We haven't decided yet. Not much more I can say really...

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!:P) 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.

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! :)

Browsers are an issue, however like all future technology, it'll get better. There are games using HTML5 already, and yes... IE6 is still out there, and XP users might stuggle. But... those are slow machines, and Game Maker DOES produce .EXE files, so let them run those. 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. Also remember some of the biggest web players are already using HTML5 to make games, so it's not like we're our on a limb here. And being an engine, if we optimise it... everyone would get the benefit. But yes... if your making a game for the web, you will have to test it in many browsers to see how it runs, this is no different from releasing a .EXE You still have to make sure it'll run fast enough on slower machines; same thing really.

D&D. Yes... the sooner we "bring it into the fold" the better. Its a long standing issue we have. it's vital, but the backbone is archaic and needs updating.

Distribution. As I said before, we simply haven't thought that far ahead yet. Who knows...

Remember this.The biggest thing about new tech that runs slowly. Machines and software get quicker all the time, so by the time you release something, the machine/spec that WAS top of the line when you started, is now your mid to baseline spec. Machines catch up. And with stuff like this,new browsers will come out that will speed the process up, you won't always have to upgrade your PC to get something, you can just download the latest bit of software. So while its a little slow just now, in a year... it may well be common place, who knows.

#29 round

round

    GMC Member

  • GMC Member
  • 167 posts

Posted 28 February 2011 - 12:46 AM

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!:P) 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!!!!
B-)

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

  • 0

#30 Schyler

Schyler

    Noskcirderf Derf

  • GMC Member
  • 2679 posts
  • Version:GM:Studio

Posted 28 February 2011 - 12:51 AM

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

Posted Image

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.

  • 0




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users