question about Love.js security

[atenzor]

OK that would be awesome, but I guess my remaining question here is... the client is the actual game let's say... but what exactly is the server tho? Is it also a love2d "game" or is it something else that just does the communication back and forth. That's what I am trying to figure out. And I am assuming this server would have to be somehow encrypted and so on and so forth.

I wish there was a tutorial for me to at least see how this would be structured, just to show me the actual idea in practice.

[Xugro]

Just a simple example: The game will be an image moving around with the arrow-keys.

client (LÖVE):

• love.keypressed()
  for the arrow keys (send these to the server)
• gamestate
  x- and y-position (get these from the server)
• the image
• love.draw() (draw the image at the x- and y-position)

server (pure lua)

• gamestate
  x- and y-position (send these to the client)
• game logic (your code)
  Since your code is on the server the players cannot see it. This is the game logic - e.g. when the player presses the up-key change the y-position. This can get as complicated as you want.

Encryption should be used between the client and the server. Additionally you should encrypt important data on the server (e.g. usernames and passwords if you need those).

This should be easy to implement locally. You just need LÖVE (for the client), a lua interpreter und lua-enet installed (for the server). Then just follow the basic lua-enet tutorial and from there implement the "little game" outlined above.

Edit: Networking and the client-server setup is the increased complexity I talked about.

[atenzor]

Thank you very much, I will check all that and see what I can do! Thanks!

[dusoft]

Can they somehow get the code?

Yes and you are missing the point.

But how does it work exactly? Isn't the game file only accessible by the hosting server during runtime?

I will test it out soon, but from what I saw, you basically have a game.js and game.data file.
It seems like the content of the code is located in the game.data file, but why would that be available
for download or whatever? It should only be accessed by the server and restricted to the end user.

JS is client side and it has to fetch assets and the Love code from the server. And if JS can do it, then anybody can, right? Fire up a browser console, go to a Network tab and be in awe of it!

Also, source code alone (the engine) is not much of use, the story and the assets and the overall working of it counts.

[zorg]

Also, source code alone (the engine) is not much of use, the story and the assets and the overall working of it counts.

Apart from playing the game, the stories can be told, the visual assets can be screenshotted, sound assets can be recorded, and it overall can be shared (think let's play videos/streams)... technically, maybe not legally.

There is one fool-proof solution though; don't release the game. That way, no one can steal it.

[Jeeper]

Good news: No one is going to steal your story, assets or code. Why? because they are not worth stealing. If they are worth stealing then congratulations, you are going to get rich before anyone else manages to steal it

[atenzor]

For me, it's not about the money, it's about someone else claiming they did what I did and I don't want that.

I want to be "known" as the only person who managed to implement that, you feel me?

[zorg]

Can't say i share the same level of vanity. You have proof you did something, others don't. And besides, what good does such a claim do anyway?

I want to be "known" as the only person who managed to implement that,

Implement what? Also, out of the 10 billion people on the planet, i kinda doubt any of us are that important to be known for anything significant; the truth of the matter is, we don't matter.

Make your game.

(And don't just want to use love.js because it might seem safer to you; it's not an officially supported platform, go for desktop löve if you can)

[MrFariator]

I think the main thing here is about how someone could basically take a love.js game, and rehost it on another website. Maybe even modify any legal notices (copyright year, credits) and some assets to effectively claim that whoever it is doing the ripping did the game themselves. Anyone who has some experience developing Flash games on the web knows that something like that can, and will happen if your game is popular enough. One of the ways to combat that is kind of what Xugro already posted, and maybe only accept web requests from specific source(s).

However, here's the thing: any dedicated enough hacker will inevitably find a way to rip your game apart, whether they are well-intentioned (modders, hobbyist tinkerers, maybe a speedrunner trying to find out how the game works internally) or looking to rip your work (piracy, asset flippers, bootleggers). Anything you will ever put out, whether it is an image, video, code or even text is a potential target for any malicious agent to dig their claws into. As such, you're effectively setting yourself up to fight a battle you never have a real chance of winning. This is not a love.js specific issue, this is something you have to deal with when putting any work out there for others to see and play in general.

Make your game, and worry about these things later. People will have to know about your work in the first place before they even consider digging their claws into it. If someone does eventually rehost your game, claiming they made it, just file a DMCA. You have options post-release.

[atenzor]

Maybe I will just make the game like a client-server thing. So client (what players have access to) is just going to be display and input (player movement), everything else is going to be handled by the server (for example on my PC or some other host) by UDP networking. There is no way for them to get the code at the very least, the assets that is OK, but for me, I just want to protect the code, and they won't be able to do it over the Internet if it's over UDP. So yes, they can maybe cheat the single player game by modifying the client (then again even that depends how I implement the server-client), but they won't get the actual lines of code used on the server for the game logic, the variables, the values, etc. So I will probably go with that approach.