It is of the Equidae family, so I am quite satisfied. That being said, let's try to stay on topic, k?Merkoth wrote:I googled it, but I must admit that it looks more like a mini-donkey o_O
Future features
Re: Future features
Now posting IN STEREO (where available)
Re: Future features
NEVER! The first one who stays on topic gets banned!mike wrote:That being said, let's try to stay on topic, k?
Re: Future features
Yup, sorry about that.mike wrote:It is of the Equidae family, so I am quite satisfied. That being said, let's try to stay on topic, k?Merkoth wrote:I googled it, but I must admit that it looks more like a mini-donkey o_O
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.
Teh Blog -> http://cryodreams.com.ar
Re: Future features
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.
Suggestions are, as always, welcome.
Re: Future features
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.
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.
Teh Blog -> http://cryodreams.com.ar
Re: Future features
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.
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.
Re: Future features
Hehe, that would only keep the truly lazy away.Merkoth wrote: Maybe using a MD5 sum of the name of the binary as password for the zipfile?
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.
Re: Future features
That is a horribly clever idea. Man, this forum is quickly becoming awesome.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.
Now posting IN STEREO (where available)
Re: Future features
Yep, love.timer:cap() would be perfect.
Re: Future features
Good. That's not really hard to implement. Version 0.2.1, then.
Who is online
Users browsing this forum: Google [Bot] and 9 guests