How Big projects can Löve2d handle?

[Schreda]

Dear All,

is it actually possible to create a quite huge game with löve2d? I know C, Ruby and Iua. Since long time now I have already a nice game idea in my mind but Im not sure löve2d can handle such big project. Does it fit more for small projects or it can handle big too? Does someone have an expierence in it?

C and C++ I wont use specially because Im just doing the development by myself... Ruby is nice but I prefer something more straight like Lua + Löve2d.
Thank you for your comments anyway
regards

[Rad3k]

I can say for sure that Löve is excellent for small projects, but I don't see any reasons why it should be bad for big ones.

I'm not quite sure what you mean by "huge" game. As far as I know, the only size constraints (besides the physical, like hardware limitations) are the ones that you impose by your design.

Be sure though to check if Löve has all the features you will need.

[Lap]

If you give us a little more of what the big project your thinking of doing involves we can try to point out any points that Love might have problems with (if any).

[Schreda]

Thanks for your reply already. I was thinking about kind of a 2d mmo game or RTS game which should be also playable via the Lan or Internet like party mode or pvp mode...
Thank you
regards

[Rad3k]

Thanks for your reply already. I was thinking about kind of a 2d mmo game or RTS game which should be also playable via the Lan or Internet like party mode or pvp mode...
Thank you
regards

I think nothing stops you from using Löve for clients. Using Lua for server may or may not be a good idea, depending on the intended load.

By the way, do you have any experience in making simpler games? Because starting off with a big project wouldn't be a good idea.

[miko]

Dear All,

is it actually possible to create a quite huge game with löve2d?

Sure it is! The question is if you as a programmer can create such a big game? I would not be afraid of löve (except maybe the physics module - I would not use it in big projects), but the programmer using it. If you can write such a big game in ruby/C, then you can do it even better using löve.

[Taehl]

Love is pretty efficient, however, you'll always be limited by hardware in the end. So it's up to you to code it in such a way that game resources and data is handled efficiently (look to other games with huge, open environments for inspiration, like Minecraft or Morrowind. Take note of how, for example, they have huge worlds, but don't dump all of it in memory at once. Rather, they load smaller, more manageable chunks of it, and load/unload new chunks as the player moves around). As another example, collision: Don't check every object against every other object in the world (because as the world gets bigger, the server would get exponentially slower). Instead, reduce it as much as possible by using quadtrees or something.

Here's a picture of one of my games, where I was testing a huge map. Not counting the FPS loss of just drawing so many tiles (which are each 64x64 pixels, but scaled to smaller than 3x3 in this case), the game ran perfectly fine. A big part of that is the way my physics system only ever checks tiles adjacent to the player, as opposed to all tiles (or checking all tiles to see if they're adjacent, then doing the physics).

[tsturzl]

.... A big part of that is the way my physics system only ever checks tiles adjacent to the player, as opposed to all tiles (or checking all tiles to see if they're adjacent, then doing the physics).

You can put physics objects to sleep so they aren't being simulated, you can allow them to go to sleep if they aren't being interacted with also. This saves you some processing power, especially if you have a lot of objects loaded in the physics world.

I'm doing a medium sized project in Love2d, and both me and my artist run at a constant of 60FPS(the fps cap), though I use up to 5 particle systems at once, drawing and simulating up to 200 particles at a time, plus I'm simulating 4 objects in the physics world.

Its definitely do-able, but MMO's and RTS's are hard, you might want to consider something more original but still lingering around the idea of MMO/RTS thats easier to program.

[ivan]

In reality, I think Lua is not a very good language for large projects.
There's a very simple reason for this:
Lua is an interpreted language so if you have bugs in your code you're not going to find them until that particular code path is executed.
The more code you have, the greater the probability for bugs which would usually be caught by the compiler in a non-interpreted language.
You CAN make a project with a lot of content but there is a reasonable limit to the amount of Lua code you can maintain.

[miko]

In reality, I think Lua is not a very good language for large projects.
There's a very simple reason for this:
Lua is an interpreted language so if you have bugs in your code you're not going to find them until that particular code path is executed.
The more code you have, the greater the probability for bugs which would usually be caught by the compiler in a non-interpreted language.
You CAN make a project with a lot of content but there is a reasonable limit to the amount of Lua code you can maintain.

This can spot only compile-time errors, but will miss run-time errors. For any large project you need a full set of tests (unit, functional, integrity, etc), no matter if the language is compiled or not. So the problem is not with the language (technology), but with managing your code (organization). If you get this right, I would not be afraid of Lua as an interpreter.