HTML5

[tprime]

I noticed I was not able to get any input read in HTML5. It worked when I was in the normal "PC" mode. I was able to have mouse and keyboard input, but not in HTML5 mode.
Any reason as to why it didn't work?

[bluemonkmn]

SGDK2 does not (yet) export the entire game when writing HTML5, as
documented in the help file, and stated at all the following sites:

http://sgdk2.sourceforge.net/
http://sourceforge.net/news/?group_id=152001
http://www.facebook.com/pages/Scrolling-Game-Development-Kit/142273489121708
http://gamedev.enigmadream.com/index.php?topic=1562.0

Reading and processing inputs and sprite rules is not on the list of included features for HTML5 yet.

[bluemonkmn]

Keep in mind, that doesn't mean you can't make complete HTML5 games, it just means that more of the coding is done outside of the SGDK2 IDE.  The reason for exporting the pieces I did is because those are the hardest to do without an IDE.

[v6v]

Are you considering adding support for such in the future?
 It's not an issue, because writing scripts to handle input and animated frames and such doesn't seem to be too much of an issue for me, but do you plan on having the users who don't have any knowledge in Javascript and the canvas to be able to execute some plans with an IDE extension for exported rules in Javascript? It seems as if that would transform SGDK2 into some form of browser-game development kit. Or is everyone on their own?

It's really not much of an issue, I just love this HTML5 feature, and I really want to know what may be in the next release of SGDK2.

[bluemonkmn]

"Considering" is the word.  I haven't quite been motivated to actually do it because there are so few people into SGDK2 it makes me wonder if it's worth the effort.  But there's always the chance that this will be the feature that makes it popular enough for everyone to pick it up .  I think I will try to add some more HTML5 support, but I'm not sure how far I'll get.  Wife got me into playing Skyrim recently, though, so I'm a little distracted, though.

[tprime]

SGDK2 does not (yet) export the entire game when writing HTML5...

When I read that part, I was hoping the input functions was not part of that category. lol

But overall, I like this feature.

[bluemonkmn]

Inputs are easy -- just add "onkeydown" attribute to the body element and make it call whatever function you want.  You can see the code in the example that was posted.

[tprime]

Thanks, I didn't think of neither of the options.

[bluemonkmn]

I have started work on trying to implement input handling for the generated HTML5 code.  The reason I didn't to this in the first release if because reading the inputs does little good if you don't have a way to map the inputs to a player.  And mapping the inputs to a player does little good if you don't have a way to map a player to a sprite.  And mapping a player to a sprite does little good if it isn't controlled by the sprite/plan rules.  And implementing one kind of rule does little good if I don't implement all (or at least many of) the rules and the whole framework for converting sprite and plan rules into JavaScript code.  So you can see this will be a very large task.  I wanted people to be able to generate HTML5 code before I was done with all that, and even if I never managed to finish that.

Did you have something else in mind when you were talking about handling inputs?  I mean inputs are defined by the sprite rules, so I have to implement support for sprite rules if it's going to work, right?

[v6v]

I'm not going to lie, it seems like a lot of ( arbitrarily ) unnecessary work... maybe a snippets of JavaScript to handle a rule, say if someone wanted to do one thing, then we could give them the appropriate code for it in JavaScript, rather than having to re-invent the entire rule and plan base for HTML5 output..

The fact that it exports the Maps to HTML5 is impressive already 

[bluemonkmn]

I think it makes sense to implement some basic level of ability to translate rules into HTML5, but maybe not all the rules.  My plan is to do what I can, then create another template project (a template for use with HTML5) that only has those rules available.

[tprime]

I have started work on trying to implement input handling for the generated HTML5 code.  The reason I didn't to this in the first release if because reading the inputs does little good if you don't have a way to map the inputs to a player.  And mapping the inputs to a player does little good if you don't have a way to map a player to a sprite.  And mapping a player to a sprite does little good if it isn't controlled by the sprite/plan rules.  And implementing one kind of rule does little good if I don't implement all (or at least many of) the rules and the whole framework for converting sprite and plan rules into JavaScript code.  So you can see this will be a very large task.  I wanted people to be able to generate HTML5 code before I was done with all that, and even if I never managed to finish that.

Makes sense.

Did you have something else in mind when you were talking about handling inputs?  I mean inputs are defined by the sprite rules, so I have to implement support for sprite rules if it's going to work, right?

I don't know exactly what you mean by that.

[bluemonkmn]

Did you have something else in mind when you were talking about handling inputs?  I mean inputs are defined by the sprite rules, so I have to implement support for sprite rules if it's going to work, right?

I don't know exactly what you mean by that.

When you said that you hoped that the input functions were not part of what was excluded, what were you hoping the HTML5 output would include?  Just the ability to read the keyboard inputs?  Or also applying the rules that link keyboard inputs to individual sprites?  (And if you expected that those rules would be generated, did you expect that all sprite rules would be generated, for moving and reacting to solidity and picking up tiles etc?)

[tprime]

Or also applying the rules that link keyboard inputs to individual sprites?

That was my original hopes, as to move the sprite with the keyboard. But then I settled with  just using the mouse, but I realized that's typically the same concept. (still involved with the sprite plans)

  (And if you expected that those rules would be generated, did you expect that all sprite rules would be generated, for moving and reacting to solidity and picking up tiles etc?)

I didn't get to far in that, since my primary goal was to have a point and click application.