Future features

General discussion about LÖVE, Lua, game development, puns, and unicorns.
User avatar
mike
Administrator
Posts: 364
Joined: Mon Feb 04, 2008 5:24 pm

Re: Future features

Post by mike »

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?
Now posting IN STEREO (where available)
User avatar
rude
Administrator
Posts: 1052
Joined: Mon Feb 04, 2008 3:58 pm
Location: Oslo, Norway

Re: Future features

Post by rude »

mike wrote:That being said, let's try to stay on topic, k?
NEVER! The first one who stays on topic gets banned!
User avatar
Merkoth
Party member
Posts: 186
Joined: Mon Feb 04, 2008 11:43 pm
Location: Buenos Aires, Argentina

Re: Future features

Post by Merkoth »

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.
User avatar
rude
Administrator
Posts: 1052
Joined: Mon Feb 04, 2008 3:58 pm
Location: Oslo, Norway

Re: Future features

Post by rude »

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.
User avatar
Merkoth
Party member
Posts: 186
Joined: Mon Feb 04, 2008 11:43 pm
Location: Buenos Aires, Argentina

Re: Future features

Post by Merkoth »

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.
SCIBOTIC
Prole
Posts: 5
Joined: Wed Feb 06, 2008 8:01 am

Re: Future features

Post by SCIBOTIC »

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. :D

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.
User avatar
rude
Administrator
Posts: 1052
Joined: Mon Feb 04, 2008 3:58 pm
Location: Oslo, Norway

Re: Future features

Post by rude »

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.
User avatar
mike
Administrator
Posts: 364
Joined: Mon Feb 04, 2008 5:24 pm

Re: Future features

Post by mike »

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.
Now posting IN STEREO (where available)
SCIBOTIC
Prole
Posts: 5
Joined: Wed Feb 06, 2008 8:01 am

Re: Future features

Post by SCIBOTIC »

Yep, love.timer:cap() would be perfect.
User avatar
rude
Administrator
Posts: 1052
Joined: Mon Feb 04, 2008 3:58 pm
Location: Oslo, Norway

Re: Future features

Post by rude »

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

Who is online

Users browsing this forum: No registered users and 3 guests