Lover - A simple CLI for developing games with LOVE :)

[jerluc]

First off, I <3 LOVE. But as I do most all of my development from the terminal, the one really annoying thing to me was the development and release process, which on OSX generally involved managing the LOVE.app file and dragging/copying files around or setting up a shell alias to point to some non-portable filesystem location.

For this reason, I've created a simple CLI called lover not only to express my undying love for LOVE, but also to help simplify the process of developing new games on this great framework, and to aid in the process of building releasable binaries of the game for multiple target platforms.

So far, lover supports the following operations:

• init - which initializes a brand new LOVE project in the current directory; this includes: downloading the required target LOVE binaries (for example, you can target any platform with any version of LOVE), creating a simple "Hello, world" main.lua, and creating a simple conf.lua with some basic default options set
• run - which runs the current project by invoking the current platform's downloaded LOVE binary (rather than a system-installed copy that may exist in some non-portable/non-standard directory)

It's far from being complete and handling every platform/LOVE version/use case, but I wanted to get this out there to maybe get some suggestions and help building this out further!

Hope at least some of you find this tool as useful as I have!

View project on Github

[Ikroth]

Hey, I just wanted to say that this project looks pretty cool! I'd like to see windows support too. Any particular reason for using Go?

[jerluc]

Hey Ikroth, thanks for the comment!

I definitely would like to add support for Windows sooner rather than later, especially considering that outside of my MacBook, my main gaming box is a Windows PC! Maybe to help me keep track of this feature request, do you mind adding an issue on GitHub with the "enhancement" label?

As for the decision to use Go for this project, my reasoning was mostly based on the fact that Go can produce cross-platform, *static* binaries, which I tend to prefer over dynamic binaries that have a bunch of dependencies to install (this makes integrating the Lover CLI into various CI tools more involved). That being said, I can easily see myself rewriting this in Python or similar in the future, as Go does have a tendency to get a bit more verbose than I could care for.

I know the obvious choice, especially for LÖVE-based game developers would be to use Lua for this project, but to be honest, outside of games, I have very little experience with the Lua ecosystem and I would definitely find myself at lost when it comes to understanding what the best choice would be for distributing this tool. If you have more experience with Lua software distribution, please feel free to add any suggestions to this issue on GitHub.

[Someguynamedpie]

well you could always just write the CLI in LOVE

[jerluc]

well you could always just write the CLI in LOVE

I think my head just exploded . But seriously this would be an interesting idea, despite the interesting bootstrapping challenge. I could see this like a thin wrapper around any existing LOVE distro, where the wrapper could:

• Create a new project from an existing project template/skeleton (similar to Lover's "init" command)
• Run an existing project by using the wrapper's internal version of LOVE (similar to Lover's "run" command)
• Package up a project by making a copy of the wrapper's internal LOVE binary for the target platform and bundling the source (similar to what I was going to make Lover's "dist" command do)

In any case, you've certainly given me some interesting ideas to think through, Someguynamedpie.

[Someguynamedpie]

build Love2D without any modules except the core ones and statically link SDL

[Positive07]

The biggest problem is zipping! LÖVE doesn't provide any utilities to do this so making .love files from LÖVE is not currently possible without external tools or libraries

[4aiman]

May I ask what is the final goal of this project?
No offense implied, but right now all of it can be done in a rather small shell script.
Especially "run" which equals to "path_to_love path_to_current_project".
Also, the chances that wget/curl is installed are far greater than those of the "go" PL.

All I'm saying is: maybe a shell script would've been better? At least those are "native" and "common".

Please, cope with me, I'm just trying to understand the necessity.

[jerluc]

Hey 4aiman, thanks for the questions!

In the README on the Github repository page, you can read at the bottom a few of the future features, which mostly equate to the goals of this project. To clarify, I'm attempting to build out this utility in order to:

• Bootstrap a brand new LOVE project from a custom project template or a blank one (presently, the lover CLI will bootstrap a simple "Hello, world!" main.lua and a basic conf.lua with a few details filled in)
• Manage LOVE binary installations; that is to say, it will be able to download and manage multiple versions of LOVE for any of the supported platforms (currently, it can download multiple versions, but only for OSX at the moment until I add support for more)
• Run any LOVE project using the correct LOVE version as configured in the project's lover configuration file (currently this works using the binary management listed before)
• Build a distributable binary for any LOVE project for the desired target platforms and versions: Windows, OSX, Linux, Android, iOS, etc. (currently, this functionality is in the works but not completed; one thing to note is that this would also rely on the LOVE binary management from before in order to download LOVE for different versions and platforms for use in packaging the distro)

Now, as you pointed out this might be able to be done with a bunch of shell scripts (or maybe one very big one), but I'd consider that suggestion similar to the previous discussion in this thread regarding which programming language would be more sensible to use. That being said, let's talk a bit more about the choice to use Go for this project with respect to some of your points about shell scripts.

First off, as you may have read in the previous parts of discussion, I am currently in the process of re-evaluating this choice of programming language. To quickly summarize my reasons for using Go:

• It has out-of-the-box cross-platform build support
• It compiles to completely self-contained static binaries (this means that despite that most users might not have the Go compiler installed, the lover CLI binary will just work as any normal executable program)
• It comes with out-of-the-box C interoperability (not hugely important for this project, but may be useful in the future)

And some reasons why it might not be a good choice:

• A major PITA to read and write
• Lacks good support for dependency management within a project
• Maybe not the best choice of language for targeting users of a Lua-based game framework

Now, regarding shell scripts, here's how I see it (and I'm assuming you're coming from a Unix/Linux/OSX background like myself, where Bash is the general standard shell scripting language):

• Shell scripts are easy to implement
• Can piggy-back off of existing utilities (such as wget and cURL as you mentioned)
• Shell scripts are particularly good at using/manipulating the filesystem (which is important for managing local files during downloads and packaging distros)

However, these are some of the disadvantages I see in using shell scripts:

• Windows-based machines have a completely different kind of shell scripting called batch files (barring Windows 10 support for Linux, which is experimental at best)
• Windows aside, it's still incredibly difficult to implement a cross-platform shell script; for example, on OSX most common Unix programs, such as grep, sed, link, tar, cURL, etc. are either not installed by default or are completely different implementations with different options (this mostly comes down to differences in BSD vs. GNU)
• There aren't many (if any at all) tools for writing tests for shells scripts; I'd like to be able to at least implement some black-box tests when new changes are introduced to ensure some amount of compatibility with previous versions
• Shell scripts are very lacking in multiprocess/threading management (not a huge disadvantage, but multiprocess downloads would make a big difference in terms of developer productivity)

With that, as mentioned before in this thread, I am currently looking into using Python instead as a kind of happy-medium between Go (which is typically moreso used as a systems-level programming language) and Bash (which is typically moreso used as a platform/distro-specific scripting language), as it has the best of both worlds: highly-portable, a lot of convenient builtins, "common" and "native", etc.

Hopefully this [very long-winded] explanation helps to clarify some of my thought process around both what the lover CLI intends to do and how I have tried to implement it.

Let me know if there are any other clarifications or questions I can answer, and thanks again for your feedback!

[4aiman]

Thanks for reply! Now I'm a believer

Ahem, I mean *now* I see why the development of this should be continued.

I have to agree that shell scripting in Windows may be a pain in one's head.
But there's no better way to know whether one can do BATs than to ask one
I guess I've been spoiled by the CodeTyphon installer which is written in shell scripts entirely.

As for me, I ceased to try to use that dark magic of BAT in Windows and prefer to use Lua scripts.
That means I have to install Lua first (or resort to using a portable x86 setup), but the readability is everything.
Besides it's a good thing to script in some easy PL so that there will be more of those who can help or catch up with the development.

Anyway, there's something to learn from CodeTyphon's installer: if you need some tool (like a free zip packer/unpacker, a compiler) - ship Lover with binaries for compatible system, download those while installing Lover or build those from source.

What I have in mind here, there shouldn't be any assumptions on what libraries and/or tools are installed.
Either this or you'd be forced to learn about "How is this or that package named in this or that distro?"
It would be easier to make a compatibility list and download/extract_from_the_installer some pre-built binary.
For example, a standalone Blender builds have their own python binaries.

I guess I got carried away. It is always possible to create a separate build for every other platform that is supported.

Maybe going minetest-way would be better (at least for those who will build from source): ship some libs within the distribution (to guarantee that it builds) but use those only if there's no installed version of the same lib.

You know, you gave me idea.