LOVE.blast(), arena shooter example game

[YellowAfterlife]

All seems working well. I think you could apply the auto-fire to LOVE version because actually there isn't nothing that we need to left alive. We wouldn't need keep clicking a button from start to end.

About online version (I really don't like to call it html5) all seems to work fine. Tested in Safari. Starts to slow and have some performance jumps with +30 enemies. I have the feeling that have less fire rate than LOVE version. BTW what you use to "compress" .JS?

Will add auto-fire to next LOVE version. As I've noticed, some people like to gather a large crowd of enemies, and then shoot them all. Because of nice effects, perhaps.

I'll try to improve performance in online version. Currently it's a pretty much 1:1 port, with exception of syntax changes, and specific while-loops being replaced by for-loop. In a perfect case I'd like this to run relatively fine on Android phones and iOS.
Actually the firerate is exact same in both versions, however it seems like I left the bug(?) in LOVE version, where the last bullet 'strikes through' the enemy, not disappearing after ones death. Not sure if I should remove this in LOVE version or add this in JS:HTML5 version.

To say, it is called HTML5 (rather than JavaScript) since it uses components of that standard - middle of the game, the Canvas element, wasn't around until that, making such games much harder to write.

I've used js obfuscator to 'compress' the file.
I don't quite like the way it processes the code (it's habit to name variables in manner of _0xNNNNNNNN actually makes the code longer for some cases), but there aren't many better alternatives - other 'packers' just remove the line breaks from code, and\or attempt to compress it, meaning that you can literally recover unchanged source via usage of tool and several regular expressions.
I hope to find (or write by self) a better one some time soon.

[Robin]

I've used js obfuscator to 'compress' the file. (...) other 'packers' just remove the line breaks from code, and\or attempt to compress it, meaning that you can literally recover unchanged source via usage of tool and several regular expressions.
I hope to find (or write by self) a better one some time soon.

Massive flamewar about hidden source in 3... 2... 1...

[MarekkPie]

Why would you bother obfuscating when you have the source code in the .love file already out in the open? Like you said, there are really only syntactical differences between the Javascript and Lua.

I mean, it's your game, but I just find that kind of silly.

[coffee]

To say, it is called HTML5 (rather than JavaScript) since it uses components of that standard - middle of the game, the Canvas element, wasn't around until that, making such games much harder to write.

Yeah, as you know that games couldn't exist without either HTML revision 5, JS and/or sometimes CSS3 and other micro-formats technologies stuff (that aren't necessarily belonging to html5) so it's "technically" wrong call it only HTML5 or only JS. But since there's isn't an acceptable good name to the cocktail mix of technologies that permits "HTML5" games and W3C only some very long time after decided to follow Apple hype of call all the "package" HTML5 (with protests of a lot of (rightful) protesters) which wasn't good for business. That only created more confusions and misinterpretations about the real boundaries of the involved technologies instead of clarification and good use of terms. Some time ago there was alternative cocktails names like DHTML, D-HTML and so on. So, I prefer instead call it "online" or anything else than actually HTML5.

I've used js obfuscator to 'compress' the file.

That's ok, I just wanted to see the source to check how close to LOVE/Lua version the JS version was. So got curious if you used some old obfuscation/compress method or if was auto-executed by some erm let's say "HTML5" game tool creator. Thanks for satisfy my curiosity.

[coffee]

Massive flamewar about hidden source in 3... 2... 1...

Marek, Robin, actually in webdesign a lot of times we aren't trying to hide nothing but we do it for gain some kb speed size (all counts and help). Be obfuscated is kind a secondary effect but not the wanted effect. It's always better and more acceptable browser spend more time decompress than loading files.

[MarekkPie]

Massive flamewar about hidden source in 3... 2... 1...

Marek, Robin, actually in webdesign a lot of times we aren't trying to hide nothing but we do it for gain some kb speed size (all counts and help). Be obfuscated is kind a secondary effect but not the wanted effect. It's always better and more acceptable browser spend more time decompress than loading files.

Aight.

[YellowAfterlife]

Massive flamewar about hidden source in 3... 2... 1...

Actually I was about to say "I wonder how that is going to happen".

Why would you bother obfuscating when you have the source code in the .love file already out in the open? Like you said, there are really only syntactical differences between the Javascript and Lua.

I mean, it's your game, but I just find that kind of silly.

Obfuscation is normally part of minification of code. The smaller JS file is, the faster page will load.
Often, this way file size lowers by half. In this case, only ~1/4, which is reason why I mentioned further searches.
Ultimately, tool of this kind shall rename all variables to shortest name possible (1, 2, 3 characters) and reduce whitespace as much as possible, resulting in smallest output and thus fastest page loading time. Obviously readability lowers too.
Mentioned online tool does some things right (see whitespace) but not other things (see naming). As can be seen from browsing processed source, it mainly focus on renaming to reduce readability rather than renaming to reduce size.

Below, a screenshot of middle of the file, displaying difference. I'm not certain in reasons to have main downloadable program in longer form if you can find equivalent open code anyway.

If a question appears, what are additional 20 lines in top of JS version, answer is simple - I did not like writing Math.* for every single case so made a 'shortcut' (function reference) table for everything used in program.

To say, it is called HTML5 (rather than JavaScript) since it uses components of that standard - middle of the game, the Canvas element, wasn't around until that, making such games much harder to write.

Yeah, as you know that games couldn't exist without either HTML revision 5, JS and/or sometimes CSS3 and other micro-formats technologies stuff (that aren't necessarily belonging to html5) so it's "technically" wrong call it only HTML5 or only JS. But since there's isn't an acceptable good name to the cocktail mix of technologies that permits "HTML5" games and W3C only some very long time after decided to follow Apple hype of call all the "package" HTML5 (with protests of a lot of (rightful) protesters) which wasn't good for business. That only created more confusions and misinterpretations about the real boundaries of the involved technologies instead of clarification and good use of terms. Some time ago there was alternative cocktails names like DHTML, D-HTML and so on. So, I prefer instead call it "online" or anything else than actually HTML5.

I've used js obfuscator to 'compress' the file.

That's ok, I just wanted to see the source to check how close to LOVE/Lua version the JS version was. So got curious if you used some old obfuscation/compress method or if was auto-executed by some erm let's say "HTML5" game tool creator. Thanks for satisfy my curiosity.

For most of things, equivalent (or, relatively equivalent) functions were made, to satisfy game's specific needs, as for example

Code: Select all

function drawCircle(x, y, r, outline) {
	ctx.beginPath();
	ctx.arc(x, y, r, 0, pi2, true);
	ctx.closePath();
	outline ? ctx.stroke() : ctx.fill();
}

Most of code differences go into draw events, where love.graphics.print() align-less calls were replaced by calls to context.fillText() calls with font align set before.

I believe, that given some time, a module can be made to map most of Love2d functionality (probably excl. Box2D and few other things), thus allowing simpler porting.
However, some functionality (like detecting width of drawn text) will still be missing, leaving numerous manual work.

[Robin]

Oh wow. Did I ever misinterpret the context.

[skeleton60]

pressing space dont start the game

[pgimeno]

Considering the game is from 6 years ago, I'd try with an older version of Löve. At the time of the last post in this thread before yours, it seems that 0.7.2 was the latest. Surprisingly, though, the game also works with 0.8.0 and 0.9.2. Check here and scroll down for older versions: https://bitbucket.org/rude/love/downloads/