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
Game Maker and HTML5
Started by
, Feb 27 2011 03:04 PM
-
This topic is locked
42 replies to this topic
#2
masterm
-
- GMC Member
-
- 1030 posts
GMC Member
Posted 27 February 2011 - 03:48 PM
All i can say is great work mike and team!
#3
conman124
-
- New Member
-
- 282 posts
The Almighty!
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?
#4
YellowAfterlife
-
- Global Moderators
-
- 3493 posts
GMC Member
- 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. 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?
#5
round
-
- GMC Member
-
- 131 posts
GMC Member
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!!!!
..... 
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!!!!
.....
Edited by round, 27 February 2011 - 04:48 PM.
#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)
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
-
- GMC Member
-
- 3196 posts
RPG Expert
- 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?
#8
HaRRiKiRi
-
- GMC Member
-
- 1364 posts
GMC Member
Posted 27 February 2011 - 05:37 PM
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.I was pretty sure Safari had the best (or very close to the best) HTML5 (and CSS3) support. But you say it's rubbish?
#9
Dark Matter
-
- GMC Member
-
- 3196 posts
RPG Expert
- Version:GM:Studio
Posted 27 February 2011 - 05:43 PM
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.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.
I was pretty sure Safari had the best (or very close to the best) HTML5 (and CSS3) support. But you say it's rubbish?
#10
paul23
-
- Global Moderators
-
- 3364 posts
GMC Member
- Version:GM8
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.
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.
#11
rwkay
-
- YoYo Games Staff
-
- 1408 posts
YoYo Games CTO
- 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!!!!
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.
#12
Cakefish
-
- GMC Member
-
- 1329 posts
I Shot The Sheriff
- 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?
This made my day
BUT our first big thing will be shipping GM 8.1, so watch this space...
This made my day
#13
Dark Matter
-
- GMC Member
-
- 3196 posts
RPG Expert
- Version:GM:Studio
Posted 27 February 2011 - 06:24 PM
I thought D&D already had their own GML functions?the first one being turning all the Drag and Drop into pure GML script, this will help considerably with any further efforts on compilation...
#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
-
- Global Moderators
-
- 6409 posts
GMC Member
- 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...?
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...?
#16
Dark Matter
-
- GMC Member
-
- 3196 posts
RPG Expert
- Version:GM:Studio
Posted 27 February 2011 - 06:54 PM
Ah, I see. Will the HTML5 games run in an actual web page then, and not in a separate window? That'd be really goodThe 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.
#17
Lapps
-
- GMC Member
-
- 693 posts
GMC Member
- 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.
#18
Smarty
-
- Retired Staff
-
- 7221 posts
GMC Member
- 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.
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.
#19
NakedPaulToast
-
- GMC Member
-
- 7203 posts
GM Studio/Mac/Win
- 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?
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?
#20
Rusky
-
- New Member
-
- 2450 posts
GMC Member
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.
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 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users
