How can I make my server application available through the Internet? Can I buy some virtual machine and run love server application on it? Should that machine contain some GPU or something?
What about fault tolerance (or how is it called)...? Can love application run several months without crash?
If server application has no window, how can I manage its behavior? Should I make console visible? Or server application can still contain window with some admin GUI? Will it unreasonably consume a lot of server resources?
You can set t.window to false instead, so that you can run löve without a window.
You can also set the module to false as well, if the server doesn't need anything from love.graphics module.
Fault tolerance isn't really dependent on whether your app was made in löve or not, of course, if you write buggy code, it might bug out.
You can make a löve app read from and write to a console... do use a separate thread for input though.
IDK about answers to the other questions.
Me and my stuff True Neutral Aspirant. Why, yes, i do indeed enjoy sarcastically correcting others when they make the most blatant of spelling mistakes. No bullying or trolling the innocent tho.
You certainly can make the server-side with LÖVE, but since you won't be using most of the framework's functionality I don't think there's that much reason to do so. You could just run LuaJIT on the server if you wanna use Lua on both client and server.
Anyway, as you're saying, you can disable all graphics (and sounds etc.) in LÖVE and have the game run without a window. It's not just useful for server-side software - there are other things you can do with LÖVE that don't require a window/graphics etc., like command-line-only games, or command-line tools/scripts. (For example, I made a script that does some image processing using only ImageData.)
As for communication over the network, using ENet or Socket is fine. You can have admin functionality available through the network and your "admin program" can just be a separate client that work just like any other client. (Of course, security is of concern here.) Having a console visible is always a good idea so you can see what the program is doing. (Likewise, the program should also print out what it's doing.)
--
Some general advice if you don't have experience with server-side software is to try to make some smaller test program so you can see through experience what problems need to be solved.
If you don't want to handle too much on low level, this is a good way to start with, as it has the basics one needs for server-client solutions.
I can even talk to you over discord when I have some time to explain a little about it. It is not much to cover though, just an offer to help out as in me explaining it also helps to reinforce it myself.
Sasha264 wrote: ↑Tue Jun 09, 2020 6:25 am
What kind of image processing are you doing with ImageData? If it's not a big secret
For example, combining a bunch of smaller images into a sprite sheet before releasing a game (for optimization purposes). There have also been a shader related thing where I needed to update the RGB values for transparent pixels in a specific way to solve a minor visual glitch.
ReFreezed wrote: ↑Tue Jun 09, 2020 12:55 pm
...where I needed to update the RGB values for transparent pixels in a specific way to solve a minor visual glitch.
Do you mean RGB values of fully transparent pixels? I did some of that too ^_^
Sasha264 wrote: ↑Sat Jun 20, 2020 9:53 am
Do you mean RGB values of fully transparent pixels? I did some of that too ^_^
Yup. Linear filtering of textures makes it pretty much necessary to fix transparent pixels next to opaque/half-transparent pixels if you don't want a black "halo" when drawing the image at non-integer coordinates or when scaling the image (not to mention mipmaps). At least it's necessary for images created in Photoshop.
