Why HTML5, and the future of exporters

Discussion and feedback on Construct 2

Post » Thu Mar 08, 2012 1:08 pm

@0plus1: at least for device access, it's in the HTML5 spec. For some browser, you can already use getUserMedia() to access Webcam/microphone. With WebRTC, you can already do p2p in the browser.
With WebGL already available in UIWebView, and doing great, Apple is going to allow webapp to use them, with the release of the new iPad (because 2048x1536 is too huge to manipulate realtime with JS only). They are slowing allwoing pieces of the HTML5 spec in Safari, because everything that can be done with webapp lighten the financial burden of validating apps over the AppStore.
And since Apple is eating alive the tablet market, the other vendors (Windows Mobile/Bada/QNX/Android...) are forced to integrate those features, to remain competitive...
B
33
S
9
G
6
Posts: 709
Reputation: 6,704

Post » Thu Mar 08, 2012 2:38 pm

I think the main trouble with new exporters which people aren't really thinking of is third party plugins and behaviors. There are already over 100 topics in the Plugins forum, and think about a few years down the line, especially if C2 increases in popularity. Imagine there being 1000 third party plugins. It's great that C2's extensibility makes it more useful to a lot of people, but on the other hand it causes a disadvantage with new exporters.

Take a new C++/EXE exporter: after a lot of work it may be possible to have an official runtime working. However, what do we do about the 1000 third party plugins? That's years more work if we try to do it ourselves. Then, the Javascript SDK is designed to have an extremely low barrier to entry: you can just pop open Notepad and type some javascript you remember from web page development, and you've got a new plugin. For a C++ exporter, plugins would likely also have to be written in C++. The tools are much more complex for this (e.g. Visual Studio is a lot more complicated than Notepad, especially if you get build errors), and the C++ language is *much* harder than javascript, you need to worry about memory and pointers and such and a great deal of things javascript takes care of for you. Not only that but if you're porting a javascript plugin to C++ double care has to be taken to ensure it's *exactly* compatible, to ensure ported projects actually work the same (otherwise there will be subtle and frustrating differences when you port your game). The question is how many javascript developers are up to this, especially if they're just hammering out a plugin in notepad in their spare time? I anticipate the majority of plugins would not be ported. Then, the majority of existing projects cannot be ported anyway due to their dependence on third party plugins. You can design a project from scratch using just the right set of plugins but one of the strengths of keeping the HTML5-only approach is all plugins automatically work on all platforms without any worry whatsoever.
Scirra Founder
B
359
S
214
G
72
Posts: 22,952
Reputation: 178,580

Post » Thu Mar 08, 2012 5:56 pm

@Ashley

You can't be expected to convert 3rd party plugins for people, and I don't think people would expect you to, so I'm not sure that would be that much of an issue, because if C2 had all of CC's base functionality, it would be plenty to make entire games with. For example, loot pursuit doesn't use a single third party plug-in, and it's quite complex.Arima2012-03-08 18:01:30
Moderator
B
88
S
32
G
33
Posts: 3,005
Reputation: 27,432

Post » Thu Mar 08, 2012 7:54 pm

A lot of the stuff these 3rd party plugins do can be done with just events; the plugins are just more convenient. Yes there are important plugins you'll want for each platform but not having them for each one is kind of expected.Tokinsom2012-03-08 19:56:09
Image
B
225
S
27
G
13
Posts: 1,774
Reputation: 18,024

Post » Thu Mar 08, 2012 8:55 pm

What a cool program this little bugger is man. I use to play around with Click Team Game Factory, MMF1.5, 2, and dev. When they release the flash export it was like super cool and when they said they were going to have an IOS Export I was like heck yeah... time to make games for Apple and make some money. I was sadden when I read their tutorial on how to export to IOS.

"Simply Click and create with our drag and drop visual interface and amazing event editor. Then a touch of button MMF will build you your xCode project, Move it to your mac and compile it to your iDevice and test it. Once you happy with your app simply submit it to Apple. MMF2 will build everything you need to submit to them, It's that easy."

"Then a touch of button MMF will build you your xCode project, Move it to your mac and compile it to your iDevice and test it."

What!, this is not like the Flash Export where it compile everything for you. NOOOOOO!!!!

Reason is I don't own a Mac but do understand how to use one and will get one some day.

So in the end this what it came down too,

MMF2 Dev :$369.00 USD
IOS Export: $129.00 USD
Mac Mini : $599.00 USD (Cheapest Mac Computer on Apple website, no upgrade. stander stock hardware)
Apple Dev : $99.00 USD

Total: $1196.00 USD

That's a lot of money spent just trying to make a game for the IOS device.

Come on, really really, but yeah no heart feeling for them. Don't get me wrong I do still love their product and still use their product to make windows and Java games tho. Not like I am bashing them or anything, but that's just a lot of money spent making game for side hobby.

Until I stumble upon http://www.scirra.com while Googleing

Free CS2 : $0 USD
HTML5: $0 USD
On IOS Device : Free
On Android Device : Free
Windows Phone : Free
Total With Mac Mini: $599.00 USD
Total Without Mac Mini: $0.00 USD

CS2 Standard: $35 USD then now $79 USD
Apple Market : $99.00 USD
HTML5: $0 USD
Android Market $25 USD
Mac Mini : $599.00 USD
Little Googleing And SDK Help : FREE
Total: with both market and Mac Mini $802 USD
Total: without both market and Mac Mini $35 USD

SC2 Business: $365 USD
Apple Market : $99.00 USD
HTML5: $0 USD
Android Market $25 USD
Mac Mini : $599.00 USD
Little Googleing And SDK Help : FREE
Total: with both market and Mac Mini $1088 USD
Total: without both market and Mac Mini $365 USD

So in the end Scirra Construct 2 is by far the best program for me in a long shot for a hobbyist.

No coding like in Game Maker, Ummm you got the Javascript SDK and the Call Javascript plugin by Joe7, and the Ajax plugin. So code away

O and in my thoughts and opinion coming from a web developer it is easy for me to pick up.

Thanks Ashley for such a great program.
B
23
S
5
G
4
Posts: 38
Reputation: 4,641

Post » Thu Mar 08, 2012 11:06 pm

@Ashley
That's the reason why you should move to an agnostic solution, like lua.
Lua has proved to be the perfect language for scripting, it's easy to use but powerful and it has been used for everything gamewise: Corona, Love, ps3 and tons of other modding tools.

I'm sorry but another dx exporter won't do any real good, as even in desktop field cross compatibility has become a must, indie games sales increase tenfold if they offer cross platform compatibility.

Just look at this list: http://en.wikipedia.org/wiki/Category:Lua-scripted_video_games

If you can convert construct to lua the exporting part is way easier as there are already solutions. Just my 2cents.
B
29
S
9
G
6
Posts: 525
Reputation: 8,294

Post » Thu Mar 08, 2012 11:10 pm

From reading their forums, GameSalad are currently undergoing a major effort to remove all Lua from their engine, because it's far too slow.

Isn't Javascript that "agnostic solution" anyway?
Scirra Founder
B
359
S
214
G
72
Posts: 22,952
Reputation: 178,580

Post » Thu Mar 08, 2012 11:37 pm

@Ashley GameSalad is not an example of a good game maker.. Corona is using lua and is powering some of the most successful apps, Lua is a wonderful language supported by tons of people and project just looks at the stats on Stack Overflow to see how much is used.

Javascript is not the solution, javascript is tied to browsers and that's the end of it. I like it and jquery has made life easier for programmers but this fact doesn't make it better than what it really is. And preferences aside my point remains: you are not using it a scripting language (like Unity does) but merely for what it is relying on browser engines to interpet it.

I don't care if it's lua or javascript or haskell or whatever, you should be using it as a scripting language to be exported into native solutions, I suggested lua because it has already implementations in both openGL and webGL. But to be honest I'm the last person that could give you advice, I don't even know how to start in writing something as complex and wonderful as construct, I'm merely suggesting ideas for products that I would buy in a hearthbit.
B
29
S
9
G
6
Posts: 525
Reputation: 8,294

Post » Thu Mar 08, 2012 11:56 pm

From what i have read in the past and what i read now, I think Ashley would love to add every exporter on the planet if he had the time and coders to help do this.
But HTML5 has took alot of his life up getting to this point, and i ADMIRE his determination to make C2 the BEST HTML5 games creator in the world. And fair play to Ashley for standing by his descision to go the HTML5 route.

But i also think that in time, EXE and other exporters will be needed if only in FULLY WORKING WRAPPERS at least.
It's a pity CC can't be converted/merged into C2, I like Lucids Proof of Concept, and i hope someone can do this.

I also like the Scripting approach, although i think Scirra's Stance is Event Driven only game making, it would add alot more power to people, like in Unity which i love being able to add to so easily during the game building, without taking too much time out making plugins.

I also know that money is a problem, but what about getting in a couple of coders spare time maybe giving them Licences or even some shares...? i dunno just an idea.tonycrew2012-03-08 23:58:47
B
40
S
14
G
11
Posts: 243
Reputation: 9,432

Post » Fri Mar 09, 2012 1:13 am

Personally, I quite like the idea of using an agnostic scripting language to make plugins (I suggest python - it's an alternative to lua that's performatic, supported everywhere, widely known and easy to pick up).
With all plugins written in such language, even if it were to be a custom language developed by Scirra, a tool could be created to convert said plugins to the native language of the exporter, maintaining the plugins compatible across runtimes.

Scirra maintains an open forum, and we're free to discuss competitors products (which shows the level of confidence they have in their product), and I also know Ashley would never diss a competitor (due to potential issues that could arise), but since I'm a regular user, I can say whatever I want, so here goes:

I've used clickteam's products since Click'n'play, and I own MMF Developer 2. Besides the slow development and lack of features (I know Nifflas is struggling to make CT implement things like modularity, code reuse, complex behaviors and a lot of cool stuff, by the way @Ashley, you should look at his suggestions for MMF, since they're all gold), the recent craze with exporter creation is a living example of what Ashley is talking about:

Since the plugins are coded in C++, and the SDK isn't good (at all), there are few plugins being developed, and nowhere near the speed we have here - the barrier to entry is too high. They had efforts to improve this since MMF1.5, with tools to create boilerplate code, new SDKs that simplify development, to no avail. The differences between compilers are too great, and you end up having to create a SDK for each IDE.
Besides that, since plugins are written in their native languages, a new SDK has to be written for each exporter (and it takes a long time, most SDKs only come out months after the exporters), and the plugins themselves have to be remade for each new exporter. This means that the product ends up full of holes - there's a plugin for flash only, another that is hardware accelerated, some other for iOs only, and so on - consistent plugins, that is, ones that work across all runtimes, are extremely rare (mostly only official extensions) - and we're not even touching the issues that came up in the transition from MMF 1.5 to MMF2 - many plugins were never converted, because they were closed source.

In conclusion, the best bet (in my opinion) for the plugin issue across exporters would be
  1. A unified language for plugin creation, that would enable an automatic plugin conversion
  2. A contract that only allows the user to create a plugin if they agree to cede some rights to Scirra (in the case of standard and free licenses, business licenses should be exempt from this) - this would allow Scirra rights to convert plugins automatically without asking for permissions
  3. A unified "store" or feature to enable people to download and update plugins (even pay for them) - the rationale is, once C2 becomes popular (and this is already happening), a ton of communities will rise and start creating plugins. This is something that happened in Clickteam, and results in a nightmare for common users, that have to hunt around periodically for latest versions, often can't communicate with authors in case of bugs, authors lose source code (this left a lot of plugins essentially unmaintainable), and some plugins are only found in weird forums.
This would obviously necessitate a lot of time spent on planning within Scirra, since it concerns the future of the company, but I think it's well worth it, even if it puts some features on hold (though please, please make containers, I really want them).

TL;DR Version: Scirra should make or adopt a plugin-making language (even if that ends up being javascript), make a plugin store/list and make a contract for plugin devs.Fimbul2012-03-09 01:18:02
B
35
S
8
G
8
Posts: 532
Reputation: 6,868

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: Artpunk and 8 guests