In regard to Löve development i have to say:
Teamwork
It's hard to develop a bigger commercial game with Löve, as most freelancers don't know this engine nor they know lua. Normally you want to musician to place and test his sounds in the game/engine himself. You may also want that the artist tests his graphics himself in the engine and the level designer has a nice editor.
Sure you can code all this on your own (like we did) but this takes a lot of time you normally don't have as it costs much more money. If the whole team with coders, artists and musicians know the Löve engine and it's rules...you can go this way.
If not, if you need to work with external freelancers or coders...better choose an engine you all know.
Löve Versioning
We started with Löve 0.7.2 and released it with 0.10.2 (while Löve is already at 11.). To stay compatible, i wrote wrappers from 0.7.2 to 0.8.x to 0.9.2 to 0.10.2 as you don't want to rewrite a lot of code. A long-term compatible version would be nice to have, where known bugs will be fixed.
Testing
Testing is very important...continuous testing of a 20h+ game is hardly possible with 2 people. But you have to!
So I wrote a bot that plays the game over and over again. He plays randomly, only a few puzzles are scripted. By random, because we wanted to test the game in a non-linear way.
Things humans would never do (e.g. open a door 10000 times).
Fortunately the bot is 1000 times faster, so it ends the game in ~40h. If you run the bot on multiple computers, you have a good test bed.
Libraries
Rely on Löve libraries! Do an in-deep research which libraries fit and are still supported. Normally library support is non existent
. So proof you can do this yourself. I released my modifications on my
github.
Choose a good, robust and easy Gui library that supports widgets of all kind.
Preferable with an WYSIWYG Editor (I know there is non
).
Sound
Sound integration is very basic in Löve.- You can do a lot...but if you work with Musicians they ask for WWISE integration or at least real time mixing or real time integration. Placing and testing sound sources and modifications is needed for a fast workflow. Coding your own system needs a lot of time (we did this, but in the end it was not very professional).
Graphics
Use texture atlases from start. But using them is a slow process for artists as they cannot modify graphics and instantly see the changes in the game. Make use of something like i did in my
gametemplate. During development use single textures that you can change fast or on the fly, but define them into an abstract texture atlas. When you do a release, just generate the atlases and you are done without any code change.
CVS and other systems
Use gitlab/github or similar. Also use their ticket-system, board or wiki for task management. For communication use discord or similar. For documents google docs is your friend. You will need lots of excel sheets for balancing and analysis.
Gameplay analysis
For balancing you need lots of data.
We have an WYSIWYG ingame editor. So we choose to not predefined all enemies and items. We placed them and tested gameplay right in the game. But because of over 60+ mazes you needed to balance the game over all mazes. That's why i wrote an lua tool to analyse all mazes, enemies and items in the game. This is exported to CSV and than imported into google docs. There we have scripts running to calculate some important values for us that we need for balancing. All this data is shared to my team member.
Logging
Logging is essential to find bugs in the wild. I used
log by rxi and it's great!
Automated builds
Do automated builds of your game from start! Invest some time at start into your infrastructure. It's very important at the end of your development where you don't have time for this. You have to trust your pipeline!
Bugreports
How to receive feedback or bugreports easily? You don't want to run an external bugtracker, you don't want to host a service aso.
So a tip. Create an
google forms with timestamp and message.
You can than "Generate a link for form with sample values". Just input some values and click "retrieve link". Just encode your stacktrace into Base64 and attach it as input field to the URL.
It's a URL you can easily fill and call by Löve (
). The Browser opens, Google Forms opens and the form is prefilled. The user can then send it off on his own. The advantage is, that you don't have to deal with ports or firewalls and you have an User agreement.
Url can look like this (userdata is bold):
The submitted data is put into an excel sheet on google forms you can browse online. So all of your team members can have access to it! You can be also informed via mail when new reports arrive.
I think it's a very cool solution.
---
All this experience is my personal view and depends on several external dependencies. It would be interesting to discuss some points later on with other devs.
All in all it was worth to choose LÖVE. It all depends on your team members and your project scope! So choose wisely which tools you need, you need to use them for a couple of years!
The löve community has been very valuable and priceless.