LÖVE

Merkoth wrote:I googled it, but I must admit that it looks more like a mini-donkey o_O

It is of the Equidae family, so I am quite satisfied. That being said, let's try to stay on topic, k?

mike wrote:That being said, let's try to stay on topic, k?

NEVER! The first one who stays on topic gets banned!

mike wrote:

Merkoth wrote:I googled it, but I must admit that it looks more like a mini-donkey o_O

It is of the Equidae family, so I am quite satisfied. That being said, let's try to stay on topic, k?

Yup, sorry about that.

My next suggestion: If we change the name of love/love.exe (depending your platform,whatever), make it look for a .love file with the same name. That way we can deliver a full game withouth using batch or shell scripts. For example, if the love binary is called "superduperracing.exe" it will automatically look for "superduperracing.love", loading it and playing it right away.

Another idea would be to "glue" the binary and the .love in one file, preventing smarty pants from peeking our code and ripping our media.

For example, if I run "love --include game.love" it will create a single .exe called "game.exe" embedding the .love file.

Both great suggestions. The first one is dead easy with the current system, but not so sure about the second one. I suppose it would require an embedded C-compiler, which is mostly out of the question. As an alternative, one could consider a loading mechanism for compiled .love-files as a .dll/.so/.dylib. Not sure how to do that platform independently, though.

Suggestions are, as always, welcome.

Yup, the second one is a little bit more complex (is it possible to append info to an executable without breaking it and without recompiling?). Now that I remember, I took the idea from an old project I used to follow (http://fenix.divsite.net), but there was a difference: the "interpreter" was a VM and the game was just bytecode. I know the mantainer of that project, I can ask him.

Anyway, the first one is both elegant and easy to implement, the other one can wait for sure. However, finding a way to protect the media is something important. Maybe using a MD5 sum of the name of the binary as password for the zipfile? It's just fool-proof, though.

Let's not forget the licensing requirements of some of the libraries you guys depend on, especially when combining your data with a binary.
I'd be happy just to have a good way to obfuscate the .love file if I was looking to do a commercial game but right now, some more tutorials would be awesome.

Also I mentioned the project in #ludumdare and a few of them were quite displeased with the fact you guys using delta timing and leave no resources for other processes.
That does bring up a good point that when pausing a game etc. it'd be nice to set a fixed frame rate or some such in order to ease up while the user is focusing on something else.

Merkoth wrote: Maybe using a MD5 sum of the name of the binary as password for the zipfile?

Hehe, that would only keep the truly lazy away.

SCIBOTIC:

• Licensing requirements? We should be okay there as long as we use the dynamic libraries. (LGLP x 3, FTL x 1, ZLIB x 1, MIT x 1 , ...)
• Timing: yes, I know. I was hoping that vertical sync would take care of that, but it seems that it does not work on all platforms or even graphics cards (at least not via SDL). It's a poor excuse anyway, since it would be useful on point-and-click/no-action games. So ... love.timer:cap(100). Is that basically what you're looking for?
• Tutorials: yeah, we need more. Making new thread for tutorial requests.

Merkoth wrote:My next suggestion: If we change the name of love/love.exe (depending your platform,whatever), make it look for a .love file with the same name. That way we can deliver a full game withouth using batch or shell scripts. For example, if the love binary is called "superduperracing.exe" it will automatically look for "superduperracing.love", loading it and playing it right away.

That is a horribly clever idea. Man, this forum is quickly becoming awesome.

Yep, love.timer:cap() would be perfect.

Good. That's not really hard to implement. Version 0.2.1, then.