What are /r/love2d's favorite Products & Services?

From 3.5 billion Reddit comments

Have you taken a look at the distribution wiki page yet?

In short, you can distribute games, without porting or shenanigans like that. It's usually just a bit of folder and file manipulation which you can do with a few commands that are provided or even automate it if you so desire.

Though for iOS development you need access to a mac. Not 100% sure if you can package for Mac on another system. I'm too inexperienced with Mac and .app files. I think it should be possible on another platform.

And for linux there isn't really a way to create an appimage yet. So you'll have to tell people to download Löve and your game (as .love)

literally on the main page of the wiki, on the last paragraph of the Welcome section, it says

> If you want to read this wiki without an internet connection, you can download a weekly generated package for offline viewing here

Click that link to download an offline copy of the wiki.

Lua's about as good as it gets in terms of performance as far as dynamic languages go, and the whole thing's architected as a bunch of performance intensive stuff (physics, audio, batched graphics, etc.) implemented in C, and exposed to Lua via the api, so performance really isn't that bad. The default main loop is single-threaded, but you can trivially rewrite it with love.thread if that becomes an issue.

I'd say the biggest downside is, as the name suggests, the limitation to 2D. There have been efforts to mitigate this, but ultimately you will be working pretty heavily against the grain if you want to do anything 3D.

You're definitely not the first to complain about this: https://love2d.org/forums/viewtopic.php?f=3&t=13300

My opinion: Americans are overly sensitive about sexual things, but these libraries tend to go out of their way to joke around with them. It would be nice if this were not an issue, but being forced to compromise by renaming the existing libraries is a disagreeable option.

I can imagine why this would make it difficult to teach Love to kids, but maybe rather than be embarrassed about it, it should be embraced? It would help keep things funny and silly while kids learn about coding and game design.

Godot is going to be your best bet.

Doesn't use Lua out of the box, but it does use two languages you can pick from (GDscript, which is similiar to python, and C#)

Someone has also written in 3rd party Lua support for it if you absolutely must have Lua.

An alternative would be https://devdocs.io - it includes the love2d docs and it can be accessed when you're offline. You just have to setup the love2d docs to be offline accessible (devdocs settings). And of course you can search through the documentation via a built-in search.

Making a game.

It sounds stereotypical, but it's how I started, and I believe it's the best way.

On the forums there are projects people have submitted, you can download them and look at the code.

But an important thing to remember is that there probably won't be a tutorial for exactly what you want to do, but you don't need it, as you can transfer what you've learnt to what you want to do.

You would need to first parse the XML into Lua, and then manipulate some data so it is love-centric. I did a similar thing with Tiled (except Tiled exports to Lua, so I was able to skip that step) with my Tiled library, Simple Tiled Implementation.

Wouldn't it be easier to store the id on love.touchpressed and then only allowing input from that id until love.touchreleased?

There's really only so simple that one can make it. Android development in general requires considerable setup, especially for someone that hasn't done it before.

I would follow the Android site's steps on setting up the SDK/NDK rather the instructions on the LOVE2D wiki, then go back to the wiki for the LOVE-specific stuff. The Android site will be more comprehensive on that subject.

https://developer.android.com/studio/index.html

Note that the wiki has outdated information here:

> WARNING: The Download button on the right is for preconfigured install. Instead go to "Get just the command line tools" and get the installer.

That is no longer the case. Instead, you click "Download Options" and you'll see the command line tools.

Just using Android Studio to setup most of it is certainly a bit easier, but the downloads will of course be larger, and you'll have to install Android Studio.

We'll need more information on the File Not Found error, because that might be a regular missing file or it might be an incorrect PATH environment variable (i.e. ndk-build itself cannot be found).

This post tells you where to move your .love source. It's written for Linux, using Linux paths, but should work the same way on Windows.

You need to use love2d specific file loading methods because a zip file isn't the same as normal folders.

dofile is from lua, and loads files from a regularly defined set of folders, including the current directory. Dofile doesn't know how to load things from inside the love archive file.

If you use require somefile, it will work, because love changes the behaviour of require to know about the love archive file.

If require won't work for you, then use methods from https://love2d.org/wiki/love.filesystem .Your best bet is probably love.filesystem.loadfile in that case.

You can download it as collection of htmls.

I don't know of an automatic way to turn those into pdfs. It is a wiki after all.

Here's the link to the offline docs: https://love2d.org/wiki.zip

Edit: Ah, you found it :)

Cheers!

house.lua needs to return house to make it visible to anything loading it. In addition, love.filesystem.load returns stuff, so you need to set its return values; it's not enough to just invoke it e.g.

local house, _ = love.filesystem.load( "house.lua" )

Generally speaking, I use "require" to load other files (similar to using "import" in other languages); I don't know what the benefits of using love.filesystem.load are tbh. Using "require" looks like this:

local house = require("house.lua")

Yes, you can make (just about) any 2D game you'd like with Love2D. All it takes is the coding of the game (and for things you don't want to code there are generally libraries made by other people).

TL;DR: You can indeed make a game like Hotline Miami in Love2D.

Edit: There are links to the forums and the wiki, which has documentation.

> I can only export for Mac if I'm on a mac myself. And on Linux, you literally have to provide the .love file (which is your source code!) and expect others to install LÖVE.

The game distribution situation isn't as streamlined as it could/should be, but neither of those statements are true. You can create a fused Mac .app from any OS (provided you keep the symlinks inside the .app folder intact), and for Linux you can either provide and installable package (e.g. .deb or something), or a completely standalone / portable build.

For the latter there isn't an official downloadable solution on the love front page yet, but work on that is in progress / being tested ( https://love2d.org/forums/viewtopic.php?f=3&t=83087 ). You can also create a standalone Linux build yourself if you have the know-how.

Regardless of your target platform, current platform, and choice of engine or framework, you should always test all versions of anything you make on all its target platforms though, when possible.

Lua's concatenation operator is not +, but rather ..

So you can do love.graphics.print("Name: " .. name, 69, 420)

You can also use lua's string.format function if you want to keep it all in one string: love.graphics.print(string.format("Name: %s", name), 69, 420)

The benefit to string.format over the concatenation is that it may be more compact if you're trying to print lots of variables. However, if I'm trying to print just one var, I tend to use ..

Concatenation: love.graphics.print("Variables: " .. a .. ", " .. b .. ", " .. c) String.format: love.graphics.print(string.format("Variables: %s, %s, %s", a, b, c))

Check the docs.

https://love2d.org/wiki/love.graphics.newCanvas

I’m on my phone right now but the idea would be. Get window height, get window width. Set your ideal resolution, let’s say 480x640. Create the canvas: myNewCanvas = love.graphics.newCanvas(480, 640)
You need to divide the screenwidth with the ideal resolution to get the multiplier for scaling: widthScale = screen width/480

If you want that to be “pixel perfect” you need to use math.floor on the scale and apply the same number on the heightScale.

It’s possible depending on how you are implementing it (if you are using math.floor) you game screen won’t cover the entire screen so you need to add an offset to your canvas on the sides to get a letterbox. For doing that you need to get the difference between your scaled canvas width and the screen. Something like cancasOffsetX= (screen Width - (480*widthScale))/2
You can apply the same logic to the height if necessary.

Then you need to draw your game on the canvas. Once you finish you need to draw the canvas with scaling on the X and Y and the offset on the position. You can check the documentation and have a play with it.

https://love2d.org/wiki/Canvas

I think the problem might be related to dofile(). I've made a few games myself (no expert here), but I've never used that, always just done require('...').

This link also mentions not using dofile, so it might be a known issue.

https://love2d.org/forums/viewtopic.php?t=3715

First of all. Consider whether you need a fixed timestep.

It makes sense for physics. And it also makes sense to run physics much more often than the game loop. For accuracy reasons.

Many games run their physics 120 times a second even if they only manage 30 or 60 fps.

The article you linked also specifically talks about game physics.

Unless you need increased accuracy.

Now to answer your question. The best way to do this would be in your love.run.

Love.run is a function called by love containing the main game loop. Usually there's no need to tinker with it. But in this example, it would make sense.

https://love2d.org/wiki/love.run

Ideally. Just use the same one and modify it slightly to fix the timestamp.

Specifically. You'll need a counter variable. You increase it love.timer.getDelta().

While this counter variable is larger than your target fixed timestep, call update with your fixed update and decrease the counter by fixed timestep.

And that's about it!

Hey there!

I would suggest using one of the camera implementations.

Hump is generally a fantastic library and has one so that'd be my pick.

But anyway. Yes there is a way!

love.graphics.translate(dx, dy)

There's functions for rotating and scaling as well. The camera implementations use that too.

It happens implicitly, if you're interested the code that controls the main loop is love.run, and it calls love.graphics.present() to do the equivalent of pygame.display.update(), but you don't need to worry about doing it yourself.

Regarding the ugly... that's only a mediocre issue really. Bad yeah. But I wouldn't call it ugly.

It is rather common that you have to build for mac on a apple system. It's a closed system and third parties don't have the compiler. Meaning you either hack something together or you need that extra step.

For example: Unreal Engine 4 requires exactly the same step.

Most of the other things can be distributed with very simple batch scripts. I agree to someone completely unfamiliar with that type of stuff it's inconvenient. Hence bad. But not terribly bad.

Also. You have to provide the sourcecode. All distributed version contain it and have it rather easily accessible. Rename your .exe to a .zip and you can look right into your files.

There are ways to obfuscate and encrypt the lua files. But in the end that won't make much of a difference.

You could try to compile your lua files (which is by the way not necessary. Love2D is interpreting them during runtime. No compilation required!). Link to guide

But it does not actually prevent reverse engineering.

Just like no other game engine does. Granted. The default state is worse and it is easier to get on source code of love2d than it is for c++ compiled stuff for example. But the code has to run. The computer has to understand it. And as long as that's the case you can retrace the steps and get to some version of the code eventually (for c compiled stuff this is assembler which is quite a barrier to be sure. But not actually preventing anything).

You can always manipulate a game, extract content and modify it. If you put in enough effort.

All you as developer can do is obfuscate it and make it harder so fewer people will be capable to do it.

For the majority of gamers renaming the .exe to .zip will already go far enough.

As that page is saying. Do the right thing. License the code properly. Compile it. And you will be just fine.

I don't watch videos for tutorials very much as everyone has a different way of doing things.

The love2d wiki is by far the best resource i have used to learn love2d. It's very mature, has documentation for everything and even examples for most.

If what you are asking is for beginner tutorials, they also have good ones on the wiki right here: https://love2d.org/wiki/Getting_Started

Good luck!

I'm assuming by 'notepad file' you mean a text file. The love.filesystem module is what you want, if you are having problems with it, either post your code and that's having the problem (along with the errors), or re-read the documentation: https://love2d.org/wiki/love.filesystem

Your code works well but I don't think that reading text is the best way to learn (especially trying to integrate networking into an existing physics system). You should start off with a simple messaging script. Networking is really really complicated sometimes, so treating it as a brand new subject will give you a good base knowledge to build on.

 

You'll want to start off with the luasocket tutorial, which goes over connections, polling, etc. Basically, you open a connection (like a highway) between the server and the client. From there, you can send 'messages' to the other computers msg queue. The messages are literally just strings, so you need to find a way to portray what your goal is: moving an entity might be "mv 8 400 300" to move entity #8 to the position 400-300.

 

Just bear in mind that sending a message isn't free. You might only send messages when an object has moved, or its properties updated. Also remember that the messages aren't instant so you may have to do some lag compensation (which is a different discussion all together).

 

Start with the tutorial, make a love script that let's you send some text to and from another computer, and go from there :)

Well... Here's a list of games from their wiki: LÖVE Games

I would also check their Forums. The quality varies, but there are some really cool games being made with LÖVE.

I can't really tell you which games on the first list have been released commercially, but I will say one thing: I will easily recommend LÖVE to "professionals". We use it as a prototyping tool at our studio, and for that purpose it is excellent.

Check the release notes for 11.3 and see if any of the changes or fixes look like they might be relevant to you. If that doesn't help, you could also try a deep dive into individual git commits between 11.2 and 11.3; it might be a regression related to some other change. If you're really serious about figuring out where the change happened you could build it from different commits between there, starting with ones that seem likely culprits, and figure out precisely where the breakage happened.

You could also see if it's still broken on git master that way. It could be a regression that's already been fixed.

Corrections:

>To access these cars, you can refer to them either as train[antelope] OR train.antelope.

Actually, it should say train["antelope"] because the table[key] notation takes a key input of either string or number. Related is the fact that train[4] is valid but train.4 is not because table.key notation only accepts keys defined by strings.

Just below that, you mentioned this notation:

function character:MoveRight() character.x = character.x + 1 end

Have a look at this to see how you got the two conventions confused: https://repl.it/CZ4y

After scrolling further, I can see that you already know how the conventions work, you just got them confused.

Another simple correction: in this line:

>function character:Attack(player)

it should probably say

function enemy:Attack(player)

https://love2d.org/wiki/love.audio.newSource You are only passing the path, that function expects 2 arguments. Thats what the error means with ”bad argument #2” it expected to get a string but never did.

You gotta use love.graphics.newImage to load the image file into a drawable image, and then call love.graphics.draw inside your draw callback.

See https://love2d.org/wiki/love.graphics.newImage and https://love2d.org/wiki/love.graphics.draw for more information.

When you create a cursor from an image file, you can set the cursor's "hot spot" using the 2nd and 3rd arguments. The default 0, 0 is the image's top left corner, so just set that to the position of the hot spot on the image.

Löve uses a virtual file system.

Long story short, both your source directory and save directory behave as if they were the same. With the difference that you can only write to the save directory and read by default favoring the save directory over the source directory (should both have a file with the same name).

So for example if you have a test.lua in your source directory and a test.lua in your save directory. When reading a file via love.filesystem you would get the test.lua from your save directory.

You can check whether a file is in the save or the source directory with love.filesystem.getRealDirectory

Yes!

With a Canvas object.

A canvas is basically an image you create while your game is running.

So instead of drawing things directly on the screen, you can draw it on a canvas first and then scale this canvas to fill out the entire screen.

love.window.getWidth() has been removed as of version 0.10.0, according to the wiki.

You can use love.graphics.getWidth() or love.window.getMode() instead.

Try the extended fork from Marty - haven't used it so far, but from what's posted in the thread, it seems to be a great version.

https://love2d.org/forums/viewtopic.php?f=5&t=85468

I'd recommend sock.lua as an easier way to use lua enet. The documentation website seems to be down (but the source is in the repo) so I'd suggest posting in that thread or opening a github issue to alert the author about it.

There's also grease as another networking option.

You could make/find a custom fragment shader that is given the sphere's center and orientation via Shader:send and renders the sphere into a simple square made from two triangles. The square's area outside the sphere could be made invisible via alpha blending.

There might be an even simpler way, depending on what exactly you need the sphere to do. (E.g. is it a globe that only rotates around a fixed axis?)

What I did to learn Lua was edit other people's creations. For Love2D, it might be a good idea to look at the forums and take apart some people's LD36 submissions. They're usually really small and easy to understand since they were made in only 2 days.

Consider posting it in the projects/demos section of the official forums!

Plug aside, Bussard is looking really cool. I'm not sure what to do besides orbiting things but I did check out the repl and it works well. Looks to me like you have a really solid foundation upon which to build gameplay.

I found that past a certain point, obtaining a stable orbit becomes very difficult: http://gfycat.com/FeminineColorlessDarklingbeetle

I think you probably have an Image, when what you need in order to be able to call that method is an ImageData. The following should show you how you're meant to use that function:

local img = love.graphics.newImage('someImageFile.png') local imgData = img:getData() imgData:mapPixel(function(x, y, r, g, b, a) -- Your code here end) img = love.graphics.newImage(imgData)

Android support is still experimental but you'll find the info you need in the top post of this thread:

https://love2d.org/forums/viewtopic.php?f=11&t=76979&sid=c678f0b3f1a10051a423a7417a31b756

What is the reason for using it as ImageData instead? Quads, and preferably even spritebatches, would certainly be the way to go if you're wanting to draw a few tiles over the whole screen.

It seems like you could create an ImageData from a tile sheet and then map each pixel from it into another Imagedata created for each tile, but that would certainly be more work than quads unless you specifically need the per-pixel manipulation that ImageData provides.

Quads are quite easy to use, especially if you're used to using a texture atlas because you simply define a rectangle and then reference it when you draw a particular image.

So I made this tiny retro virtual handheld game for LCD jam. The code itself is just 140 lines but everything other took me 2 days to finish. I didn't even make the graphics myself. I used icons made by Olly Holovchenko (Creative Commons) that are called Tasty Icons and they are really tasty. Most of the time took the packaging, creating screenshots, videos, music, itch.io page etc etc. I made my own 6s long soundtrack :) and after finishing the game I extended it to a full song (which still sucks, but I'm learning :) The game is written in lua (Love2d).

Thanks for making this library! I've been wondering what to do about itch versioning for people who don't use their app and this seems like a good solution.

Looking forward to using this on projects in the future :)

Have you heard of Mari0? http://stabyourself.net/mari0/ This game was made with an older version of love but I'm sure the source code has some inspiration. Keep it up you are doing great!

I used neither. But I experimented with blender a little: http://www.datafilehost.com/d/fb876a95 Just a proof of concept like demo showing how to export blender models and animation data to use the in 2D games. Sorry for the poor model and missing textures. I am not a graphic artist.

Performance is great, Lua is probably the fastest dynamic language out there because of LuaJIT.

I will list some few downsides:

• It's not exactly beginner friendly. I mean, It doesn't have a UI to help you like Unity does, instead it gives you the basic stuff you need to build your game. I don't think this is a bad thing at all, but I know this may be a turnoff for some people.

• HTML5 support. Is not exactly a thing... I've seen a effort from the community to solve this problem, including some interesting projects like love.js, but I wouldn't say its quite there yet.

If you don't care for any of this you will probably have a good time with love2d. I'd also recommend you to have a look into openfl, it's a pretty neat engine and even the latest official Power Ranger game is running on it!

love2d.org/wiki/Notepad++

From within Notepad++, press F5 to bring up the Run command.

Click the [...] to bring up the browser, and find where you installed love.exe (or if you have the portable version, where you extracted the zip to).

Select love.exe as the program to run. This will show the path to love.exe in the "The program to run" line.

Here's where you need to be a bit fiddly:

First, put quotes around your path (e.g. "c:\your\path\to\love.exe")

Then add a space.

Then put, in quotes, "$(CURRENT_DIRECTORY)"

So you should now have: "c:\your\path\to\love.exe" "$(CURRENT_DIRECTORY)"

Next (the rest is optional, but highly recommended), click [Save...]

Give it a name (e.g. Love) and a shortcut (e.g. SHIFT + F5).

Now you can just press SHIFT + F5 (or whatever shortcut you assigned) from main.lua to run your game.

You can disable unused love modules in your configuration file. It's is a good practice to disable modules that your game doesn't need. Not 100% sure if this will solve your problem, but i think it should do it.

​

-- at conf.lua function love.conf(t) t.modules.joystick = false end

​

https://love2d.org/wiki/Config_Files

Why are you implementing your own collisions instead of using love.physics? Physics bodies that are sensors cause collision events, but don't do anything to resolve their collision so you can handle collisions however you want.

Here's an example.

Well, it says right there in the error message: you're not giving argument #2 to love.audio.newSource; it expects a string (specifically, the Source Type, ie. the type of audio source given in argument #1) but got no value instead.

• https://love2d.org/wiki/love.audio.newSource

• https://love2d.org/wiki/SourceType

Interesting issue. Perhaps not an "official" solution but you could write your own print function and use Font:getWidth to space out the characters.

Edit: Disregard. I realize now that character joining is more complicated than that.

Use the functions inverseTransformPoint after the desired scale transform. In this case using (1,1) as arguments should get you the equivalent x and y ratio.

Beware, it also takes into account the rotations.

https://love2d.org/wiki/love.graphics.inverseTransformPoint

Do a love.graphics.push at the start of love.draw before you love.graphics.translate, then just before you want to draw things on the screen above the game you use love.graphics.pop to undo the translate.

Info here: https://love2d.org/wiki/love.graphics.push

I see. My suggestion then is not to update the screen so often. You can keep polling events from the OS and update the state but only redraw when needed.

Protip: <code>love.run</code>

Is there anything in particular you'd like to learn? I'd be interested to see what a newcomer is looking for directly.

To answer your question directly, tutorials on the language itself (like local vs global variables, tables, etc) should be the same, as the version of Lua that Love has used in the past up until now is relatively static.

General concepts like how to create a movable character or non code-specific tutorials likely are still a good guide, even if the code they write isn't directly transferrable to your project.

The wiki always has updated docs for the most recent release in terms of what each function expects for arguments, and what it returns. Make sure the version you're using to develop on matches the version you see in the upper right.

If you have specific questions, either start a thread under this or DM me. I've been working with Love for 5+ years and I could help you out some if you'd like.

I use the APKTool method and it works fine for me. What problems are you having? Here's my Makefile target for android for a recent love2d project, in case that helps.

You might want to look at the docs for love.run.
https://love2d.org/wiki/love.run

It looks like that last bit,

if love.graphics and love.graphics.isActive() then love.graphics.origin() love.graphics.clear(love.graphics.getBackgroundColor())

if love.draw then love.draw() end

love.graphics.present() end

might be what you wanna control. If you write your own love.run but change that to, say...

if love.graphics and love.graphics.isActive() then if myGame.mustRedraw then myGame.mustRedraw = false love.graphics.origin() love.graphics.clear(love.graphics.getBackgroundColor())

if love.draw then love.draw() end

love.graphics.present() end end

then it should achieve what you want. However, I've never messed with love.run so you should experiment.

Alternatively! If you make a canvas the size of the screen and draw that every frame, that shouldn't take too much GPU power. Then you can lazily draw to that canvas however you want.

Are you trying to package into a .love file or into a MacOS .app file? The processes are slightly different.

Creating a .love is easy; you can just select all the files and folders in the game's root directory, compress them into a .zip and then rename it to a .love file (i.e. renamed Archive.zip to Archive.love). Note that as far as I can remember, you can't just right click the game's folder and zip that; you have to enter the folder, select all the files and folders inside and zip that (so the hierarchy of the zip archive is the same as your folder, essentially). You should then be able to run the .love file with love i.e. love Archive.love.

If you want to create a .app file as well, you want these instructions further down the page; you'll need the .love file created above anyway.

EDIT: in case it's helpful, here's the macos target of one of my love Makefiles.

macos: # Clean out existing builds rm -rf build/macos mkdir -p build/macos # Make a copy of the regular love.app for packaging my own game. cp -R lib/love.app build/macos/Game.app # Create the .love file with the game's code inside the .app; # exclude files checked into source control but not needed for running the game. cd src; zip -r ../build/macos/Game.app/Contents/Resources/Game.love * -x ".tmx" -x ".psd" # Icons and manifest; these won't stop your game from working but are nice to have. cp lib/Info.plist build/macos/Game.app/Contents/Info.plist cp src/assets/images/Icon.icns build/macos/Game.app/Contents/Resources/Icon.icns rm build/macos/Game.app/Contents/Resources/GameIcon.icns rm 'build/macos/Game.app/Contents/Resources/OS X AppIcon.icns'

Enet might be of use to you, it has Lua bindings; https://love2d.org/wiki/lua-enet

Although, i've only had experience using it with C++ in the past, so can't really provide any examples of it being used in Lua/love2d.

I don't have any experience with AdMob, but found one library that integrate admob with LOVE:
https://love2d.org/forums/viewtopic.php?t=84226

Surely it's possible, but the repo seems like it's not being supported,

Last commit is from 2017...

There's a built in Love function called love.keyPressed that does this for you. You can just put your logic for key presses in there.

Another note: there's the love.keyReleased counterpart as well so you can potentially create a state table with those 2 functions

A month ago you asked how to move a text label on/off screen. Now you're asking about networked multiplayer?

Here is what you will need: https://love2d.org/wiki/lua-enet

Now, I recommend reading that page, and then NOT doing any network programming with LOVE until you are much more experienced. Come back to this after a year of constant practice.

I'd probably go with imgui to save time. Godot's GUI has a lot of man hours behind it, if you want to use a GUI then Godot is for you. However, I've seen some pretty cool attempts at a love2d editor like sandsmas: https://love2d.org/forums/viewtopic.php?t=82881. There was also a really neat one for some point and click project that looked really, really sleek.

I don't know, but that seems reasonable.

You could take a basic demo app like lovalanche and zoom out while increasing the number of objects. Then you can get a handle on the raw performance.

https://love2d.org/forums/viewtopic.php?t=1782

At the start of your love.draw function use love.graphics.scale to change the size of the end picture and love.graphics.translate to center it.

setTextInput enables and disables the textinput callback. The co-ords seem to be for displaying an onscreen keyboard*. Use the callback to handle text being entered, the example on the wiki has a string appended with each character entered.

I've used the callback before but didn't realise it could be disabled.

*EDIT: The coords are to tell the Android/iOS keyboards to avoid that area

You can create an image object from image data.

> love.graphics.newImage

Not entirely sure about how to save it since I never looked at anything like that.

You can use love.window.setMode() to change the window size while the game is running: https://love2d.org/wiki/love.window.setMode

If you plan on keeping the window the same the whole time, you should set the window size in the config file: https://love2d.org/wiki/Config_Files

Delta time is an important concept that's among the trickier things for beginners to understand - I somehow forgot to cover it! Delta time is actually the inverse of the fps - it's the amount of time that's elapsed since the last frame, in seconds. If the game is running at exactly 60fps, dt would always be 0.0167 (or 1/60). (Of course, the framerate generally will fluctuate a little for various reasons, and that's part of why dt is important as I'll explain below.)

If I had simply written

playerX = playerX + 10

then, if the game started lagging, the player would move more slowly. Since I included dt in the motion calculations, the actual movement speed will always the same regardless of how well the game is running. This is important both for large lag spikes and for evening out small stutters that would otherwise be jarring.

Also, when you're multiplying something by dt, you can think of it as "pixels per second" (eg. 100*dt is a movement of 100 pixels per second.)

As for multiplication (and division), that's one of many things that modern computers can do extremely quickly, so I wouldn't worry about it! That's good that you're considering performance, though. Just keep in mind that "premature optimization" can potentially be a waste of time - it's usually best to try out the obvious solution to a problem before worrying about whether it's fast, so you don't spend a bunch of time speeding something up when it was never slow to begin with.

You can also keep an eye on the love2d wiki for performance tips like the one on love.graphics.newImage - they've documented many of the major newbie pitfalls.

Yeah, I also forgot to mention the double-jumping issue! We'll be able to fix that once there's a proper collision system. (I'll write the next part later tonight.)

It's important to emphasize that a .love file is essentially a zip file and that the game can generally only access certain things directly.

https://love2d.org/wiki/love.filesystem > Provides an interface to the user's filesystem. > > This module provides access to files in specific places:
> ◾ The root folder of the .love archive (or source directory)
> ◾ The root folder of the game's save directory.
> ◾ The folder containing the game's .love archive (or source directory), but only if specific conditions are met.
> ...
> Note: All paths are relative to the .love archive and save directory. (except for the get*Directory() calls)

Are you sure this 'scn loader' of yours is working correctly? I don't see any way for you to tell if anything strange happened, other than the image not being present/loaded. Why did you put in love.update instead of love.load?

If the folder structure looks like this:

game.love/folder/scn_test.lua

then it should work. If it looks like the following:

some folder/folder/scn_test.lua (where game.love is in 'some folder')

then it probably won't work unless you can figure out what the conditions mentioned in the wiki page are.

Is 'scn_loader' a function or an object? Maybe you're doing something wrong there?

STI (Simple Tiled Implementation) may be what you're looking for? Combined of course with Tiled itself, for creating the tilemaps themselves.

STI forum URL: https://love2d.org/forums/viewtopic.php?t=76983 Tiled URL: http://www.mapeditor.org/

You could write a shader to make a block look like it's damaged, and you can use shaders to create semi-realistic looking smoke. I don't think either of these things would be too difficult for a beginner to do, but the question is why do you HAVE to use shaders to accomplish these effects?

You can use sprite sheets and particle effects to create blocks that look like they're crumbling, and instead of using a shader for smoke you could just semi-transparent particles and manipulate alpha and scale to make it look like smoke.

Here goes an example of a smoke shader in love2d.

https://love2d.org/forums/viewtopic.php?f=4&amp;t=3733&amp;p=167865#p167865

If your game has been fused (you've turned the .love into an .exe), you can mount the application's directory - see love.filesystem.getSourceBaseDirectory. This will let you load the file as if it were in the .love

Also note that Though love.filesystem is sandboxed, you should be able to directly use Lua's io library, which Love doesn't block.

~~mapPixel isn't a function that exists in love2d. If you're looking at an example, make sure it's not made for a different framework than love2d.~~

Anyway, the easiest way to color an image red is to call this before drawing the image:

love.graphics.setColor(255, 0, 0)

Make sure to take a look at the wiki.

reply to myself: gamepad mapping is available since 0.9.0 using a virtual gamepad approach. And a loadGamepadMappings recently introduced in 0.9.2 supporting mapping config files.

Definitely tactile is over this mapping stuff, it just simplify the use of different input methods. I'm I right?

External files can be accessed according to https://love2d.org/wiki/love.filesystem

This seems to imply that it first looks inside the .love for reads, and then after that, looks in those specified directories. Why not place a file according to those specs, outside the .love, and try to load it?

Although largely this seems to imply that you'll only be able to load from the so-called save directories. Which can be handy if you're loading, say, preview screenshots of save files.

You're trying to execute the compiled code if you get that error.

You could also try compiling them inside Love2D, it'd look something like the example I made above, except you'd be saving the data in the user folder (see love.filesystem), then copying it into the .love file.

Let me know if you're still having issues, I could probably make an example, though that'd be tomorrow :)

I have a class called input. This class has a table containing a list of buttons I care about, like: input.buttons.left, input.buttons.jump, etc.

Once per frame I call input:update() which copies the buttons table to lastFrameButtons and then updates buttons with the current state.

Now, because I have the last frame and the current frame I can compare them and see which buttons were not pressed previously but are pressed now. These buttons get set to true in a buttons.newPress table.

I usually have the input:update() at the beginning of my update() function so through the rest of my update code I can do checks like:

if input.buttons.newPress.jump then -- Start jumping end

if input.buttons.fire then -- Player is holding down the fire button end

This is nice and clean. The other benefit of wrapping this up in an input class is that the class can map input from different keyboard keys and joysticks to one action. So hitting the right arrow key, the "d" key, or pushing right on a joystick can all cause buttons.right to be true. It's very elegant.

I use that technique in Unrequited which supports keyboards and joysticks. The relevant code is here: https://github.com/GloryFish/RedditGameJam-05/blob/master/input.lua

Lua doesn't have classes...

As others have said, the problem is that you're doing Shield:move(up) instead of self:move(up).

The reason for that would probably be easier to understand if you didn't use a "class" library that implemented OOP for you. If you do it yourself from scratch using Lua functionality rather than a library, you'll probably grasp how it works better.

Read the following chapter in Programming in Lua: https://www.lua.org/pil/16.html

It sounds like `all()` is a built-in thing in Pico-8 that's doing something like what `pairs` does. `pairs` and `ipairs` are built into the language.

&#x200B;

Helpful reference: https://www.lua.org/pil/7.3.html

The problem you're having is that you're attempting to get the values from variables as if they were table elements.

To fully understand, you need to understand the difference between the two. * Tables * Variables

From your code, you seem to already understand that variables "hold" data/information, so I assume you've not totally grasped tables. So I'll just explain it in very very simple terms.

Think of tables as a big variable (table) that contain a number of smaller variables (fields). Kind of like a file cabinet that holds folders. Each field is assigned via a key.

-- a table must exist before you add fields to it a_table = {}

-- assign a field to a key a_table.[ 'a_key' ] = 'a string field'

-- can also be assigned this way a_table.a_key = 'a string field'

-- can be accessed the same way print( a_table.a_key ) -- or print( a_table[ 'a_key' ] )

There are rules to how to use tables that I did not toouch on, but I hope that helps you understand why you're getting that error

You could also try Godot. I used Unity for a while, but it wasn't for me either. I like Love2D a lot, but it is too minimalistic for me. Godot hits the sweet spot between assisting you and not getting in your way.

You can create app for Android, and you can share the app with other people. Getting started is as simple as downloading LOVE for Android and following instructions there. Later on you can build your own APK with custom name and icon, but this version should be good enough for development.

Note that the framework is best suited for games. You can ask where is the screen touched and you have full control over drawing graphics. There are no UI elements in LOVE, you have to find a library for buttons, edit boxes and such. Also your app won't be so integrated into OS, for example it would be hard to make it default app to open content type or to share with other apps.

Oh you sure can! I just finished my first game, it was a pain in the ass to actually use admob/sense but it works.

Only if you want, you can see it working here as proof: https://play.google.com/store/apps/details?id=com.copitosystem.survivalcow

Entirely programmed with love2d. Uploaded then to google play

I know for a fact there is at least one: https://play.google.com/store/apps/details?id=com.binarycocoa.humbleboco

It's a game that I helped with. I wasn't involved with the Android port, so I can't be for certain, but I believe it uses this: https://bitbucket.org/MartinFelis/love-android-sdl2/wiki/Home

> https://store.unity.com/compare-plans

Free for those whose ENTIRE BUSINESS (if a registered business) or PERSONAL (If operating as a sole trader) earnings totaled less than $100k in the last 12 months. (not just profit, income of any type) also don't include all unity features. Price then goes up from there.

> Unreal License

Unreal Engine End User License Agreement for Publishing: This license is free to use and incurs 5% royalties when you monetize your game or other interactive off-the-shelf product and your lifetime gross revenues from that product exceed $1,000,000 USD.

(so basically free for most of us mere mortals, and if you make over 1 million dollars from a product I'm sure you'd be happy to give unreal 5%!) - note that unlike unity this is on a per-product basis and is only for a product made with unreal, not ALL income from all sources for your company over 12 months.

The question is a complex one and everyone has their take on it, depending on their experience and perspective. In my perspective, it's a good foundational framework for someone that wants to program their own game engine and deploy the game across mobile platforms. A unopinoined answer is on Itch - Most Used Engine web page where they show the most used game frameworks/engines people choose.

--Reasons I'd choose Love2d --

1. Its completely free
2. It deploys on IOS and Android
3. Don't need to learn C++/C to make cross platform game, Love2d takes care of that effort.
4. For solo game development of small games

Of course, plugin is a simple way to run love, but you actually no need any plugins for this, you can just create custom task: https://code.visualstudio.com/docs/editor/tasks#vscode

It should look like this:

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "run",
      "type": "shell",
      "options": {"cwd": "${workspaceFolder}"},
      "command": "love ${workspaceFolder}",
      "group": {
        "kind": "build",
        "isDefault": true
      }
    }
  ]
}

Wow I love this, the art looks great and in general it looks super polished and smooth. Awesome job!

I've also fallen in love with love2d over the past year; coming from other larger engines, it just feels so fast to develop in, especially once you've got some general game systems code written. What are you using for your level editing? If you haven't tried it already, I personally use Tiled and it works great with Love2d.

The answer to your question depends on the structure of your code.

&#x200B;

How are you handling game states?

How are you handling button presses?

Here is a very simple way of implementing want you want to achieve:

https://repl.it/@BruceBerrios/Simple-Back-Button

In love.mousepressed we are setting show to true any time the LMB is clicked. We use show in the loop to determine if the button function should be called. Right now if you click and outside a box and then hover over one we call the callback function. What we need to do is reset it.

If you check out the default love.run, you can see the order love callbacks are called.

The order is:

1. signal handlers (like love.mousepressed),
2. love.update and
3. love.draw.

Knowing this, the easiest way to set the value of show back to false with your current setup is to add show = false to the end of your love.draw function.

Alternatively, you could define love.mousereleased callback like

function love.mousereleased () show = false end

Both of the above approaches suffer from the "mouse drag to click" issue, where when you click outside the box and drag your mouse over the box the button function is called. This is not a major issue but it can be fixed by switching the logic above around. Move the logic you have in love.mousepressed to love.mousereleased and keep the reset show = false at the end of your love.draw. Now you the function will only be called when the mouse button is released (behaviour we have been conditioned to expect with our UI).

example

If you don't understand stencil - but what a simple version of it, check out scissor. It will limit you to just a rectangle which doesn't give as much freedom as stencils do - but makes the process simple with a single call. love.graphics.setScissor

local lg = love.graphics
love.draw = function()
  lg.setScissor(10,10,love.graphics.getWidth()-20, love.graphics.getHeight()-20)
  lg.rectangle("fill", 0,0, love.graphics.getDimensions()) -- Tries to draw a rectangle, but it won't be able to outside the scissor rectangle
  lg.setScissor() -- remove the scissor
end

I can't suggest a better way than to print by one letter, but this one seems doable.

There is a function https://love2d.org/wiki/Font:getKerning that can help you at least with that part. Distance = angle in radians * radius, so if you know the radius and the distance, you can calculate the angle difference.

> I was just about to ask if Love was still being developed.

Most of the development chat happens in the forums rather than here. The repo is hosted on Github as well and is pretty active if you're interested in dev builds for 12.0.

> I was just about to ask if Love was still being developed.

Most of the development chat happens in the forums rather than here. The repo is hosted on Github as well and is pretty active if you're interested in dev builds for 12.0.

Do you have a conf.lua where you main.lua is?

https://love2d.org/wiki/Config_Files

add this in the conf.lua:

function love.conf(t) t.console = true end

I was using the Love IDE extension
https://atom.io/packages/love-ide
I'm not really sure as to why it was causing the weird behavior though. The only reason I think Atom was the problem is because the problem stopped once I got rid of Atom.

Thanks for the reply. There are no metatables that I know off in the project. I tried all the examples on an empty main.lua, and all of them produced errors.
Seeing how the code seems to run just fine for everyone, I'm starting to suspect the problem might be my development environment.
I'm currently using Atom with this Love 2D extension.
What do you use?

Interesting, I tried on an empty project as well, but got that same error.This is the main.lua I used.

function love.load() test = {"String"} a = string.sub(test[1],1,-1) print(a) end

function love.update() end

function love.draw() end

I'm starting to suspect it's probably my installation of Love2D that might be causing the problem. What version of Love2D are you using? Did you install LUA separately? And also are you using Atom with the Love IDE extension?

thanks for the reply BTW