How to run love2D project on localhost?

[notcl4y]

Like so you won't have to close the game and open it again when you've made changes. Instead it will update itself after every change you've made and keep some variables

[Hugues Ross]

Sounds to me like you're not looking to run a server on localhost so much as you want to hot-reload your game's code and assets. It's possible, but I wouldn't say it's terribly simple. You need a system in your game's code that can respond to filesystem changes and reload the appropriate code or assets. This can also have a cascading effect, if certain elements depend on each other. But it is possible, I've made a system like this for one of my games' assets (but not the code).

As for how... the exact solution will involve OS-dependent libraries. On linux there is inotify (more specifically, I use linotify for this), and Windows has its own system (but I don't know a lua library for it off the top of my head, you would need to find one). Then, you'll have to consider a few things:

• When loading something, you need to check if the parent directory has been registered for file system events. If not, you do that
• Generally, checking file system events is something you'll need to do as part of your main loop.
• When you receive an update event, you need to reload the file and update all relevant references in the code. For assets this is pretty straightforward if you add a layer of indirection by passing a 'wrapper table' of sorts that can have its contents swapped out. For code, you need to re-register events, and also re-create objects in roughly the same state as they were in previously. That will certainly have an architectural impact, that I don't really want to untangle right now. Whatever you do, you'll probably want to track the files and their 'reach' in some kind of centralized lookup for convenience.
• When you receive a delete event... this doesn't necessarily mean the file was deleted. Different editing programs have different schemes for saving data, and depending on how they approach the problem the events you receive can be different: for instance, a deletion event followed by a creation event.
• You may need want to track the sequence of events happening to a file over more than one frame to ensure you're not loading bad data by jumping the gun while it's still being written.
• Move events are usually safe, these typically come from the save scheme of "write to a temporary file and move it over the original to prevent partial-write corruption".

Ultimately, I would classify a task like this in the "if you don't know how to do it already, you're not ready" bin. Hot-reload is a fairly complex beast depending on how far you stretch it. Keeping a couple of files in sync is easy--replacing core systems can be much harder. So my final recommendation: Consider what exactly you want to reload, beyond just "everything". Tracking just one or two files holding some core functions and not creating anything will not be that hard, won't require much in the way of structural work (as long as you properly isolate the code) and will probably provide most of the value you actually want.

EDIT: Forgot one thing. because the relevant libraries are OS-dependent, you can't easily ship the reloading code unless you want to give up supporting other platforms. But that's not too hard to avoid, you can just check if the library is present and skip the code if it's not.

[notcl4y]

Ok thanks

[GVovkiv]

ZeroBrane has interesting feature "live coding" http://notebook.kulchenko.com/zerobrane ... -with-love where with it, you can update variables when game is run, which partially covers need for fine tuning variables (physics, gameplay, etc). You can even edit them with mouse.
And i think, some big IDE like VSCode also can do similar thins (especially with addons).
But, yes, as Hugues Ross mentioned, to achieving even partial hot-swaping, you actually need code game that it way.

[zorg]

Besides what has been said, the whole OS-dependent stuff is completely not needed considering that love.filesystem.getInfo can return the last modified time, so if you just query that in love.update for instance, and compare it to saved values for whatever files you want to detect, then at least the restarting the project based on that is completely simple and doable.

The hard part is restoring all the state to the point where it was.

[Hugues Ross]

Besides what has been said, the whole OS-dependent stuff is completely not needed considering that love.filesystem.getInfo can return the last modified time, so if you just query that in love.update for instance, and compare it to saved values for whatever files you want to detect, then at least the restarting the project based on that is completely simple and doable.

The hard part is restoring all the state to the point where it was.

That's an excellent point! I hadn't considered such an approach because it wouldn't scale up to my current project's size, but indeed it probably works great for most games.

[pgimeno]

T2R implements state save/restore. Making a change involves restarting, but resuming where you were is pretty fast - start the application, press a key, press 4 for Load Game. It sort of voids the need of trying to automate what can't be reliably automated.

[soulmata]

There are a number of ways to pull in code and adjust it on the fly, but it depends on what your goal is and what your experience level is. I'm going to suggest, in order of complexity, the following methods:

• Persist certain game state tables to disk that you can reload on demand

• Persist entire game state to disk that you can reload on demand

• In-game console to set and fetch game state variables

• Persistence module to use LOADSTRING on saved functions

• Unrequire/require

For the first 2, all you need to do is use any persistence module to write out the contents of a table to disk that your game uses for tracking state, and reload it later. Of course, I say "All you need to do", but there's always a hundred gotchas. One big gotcha is that not everything can be persisted - more on this later. Another big gotcha is that you'd need a way to avoid clobbering some other state you wanted to preserve if you're talking about just certain variables - which is where the third option is. In my game, quicksave/quickload do exactly this - all state related to the current running game can be saved to disk or reloaded on demand at any time, but things regarding the game setup (loading assets, profile settings, etc) are not part of that state.

For option 3 - if you just want a way to adjust certain variables in the game, an easier way would be to write an in-game developer console that you can use. I wrote one for my game that allows me to fetch any variable in the code, like so:



The console allows me to inspect anything in the game state and modify any variables that might be in the game, or run specific functions with specific arguments. You can add any functionality you want to that, including calling any function in your own code with any arguments, short of recompiling functions. You could also, theoretically, even paste in something that parsed to a valid lua function and tell your console to use loadstring and treat it as an anonymous function you could call. This is intermediate difficulty but probably the biggest value overall, though I wouldn't really recommend having a way to paste in function data.

For the last 2, these are more dangerous. If you are talking about logic changes, that's much more complicated, but not impossible. The two methods I would would be Unrequire and reload a module or Load an anonymous function from a file on demand.

The latter can be done with a persistence module, and it will re-load the code via LOADSTRING which you can then re-execute. Of course, this easily runs the possibility of you crashing your code if you try to call a method that doesn't exist or something. I did it during development, but now that I have released my game as a commercial product, I removed that ability because it introduces a strong risk of arbitrary code execution exploits. You can use this method pretty easily though, and if you want to be careful, you can first evaluate with pcall if something can execute, then use its logic. Here's the problem - in order to do this on a mass scale, you'd need to be using persistence to load and unload your modules, which itself takes a lot of setup to do properly. So it's not impossible, it's just a bit of a headache. The biggest gotchas here is that you need a way to generate the loadstring payload that will parse out the way you want, which itself is a hassle, and that you CANNOT persist upvalues. So anything using an upvalue just straight up won't work.

The former method can be implemented without persistence, though I got to be honest, I'm not entirely sure if this would result in the lua compiler actually rebuilding the source module. Basically, you'd unrequire like the below example. I actually use this in my game for 2 modules, light world and SUIT, to get around certain performance issues:

Code: Select all

function unrequire(m)
	package.loaded[m] = nil
	_G[m] = nil
end
--unload and destroy lighting objects
function f_ed_unload_light()
  f_ed_clear_lights()
  unrequire('modules.light')
  collectgarbage("collect")
end

You can then re-require the module as desired, but I'd have to test if that actually rebuilds it. If that does rebuild it, that would be the cleanest way to do it on demand.

[tourgen]

ZeroBrane has interesting feature "live coding" http://notebook.kulchenko.com/zerobrane ... -with-love where with it, you can update variables when game is run, which partially covers need for fine tuning variables (physics, gameplay, etc). You can even edit them with mouse.

that's really useful and I had no idea zerobrane could do that. I should probably read the docs at some point.

[GVovkiv]

that's really useful and I had no idea zerobrane could do that. I should probably read the docs at some point.

There actually tons of cool small features, to learn about you need to dive into docs and some confgs (in form of lua scripts, because guess what: this lua ide actually written in lua) since this program doesn't even has options window