LÖVE

Hi everyone!
I've been toying with LÖVE engine for quite some time in the past, but to be honest - I've never actually finished even one game. (Had much better luck with some more popular engines). Now I'd like to get back to LÖVE - I like the simplicity of it, speed of deployment etc. It's just... cute.
The problem is that I'm normally a JAVA developer, and when I'm writing any code I'm always thinking in OOP. I always prefer to have my model and presentation decoupled. And if I remember correctly I found working with OOP in lua tedious. Writing such stuff in java is a breeze, and when you need to change some stuff, all the IDEs provide you with very good refactoring functions. In lua, even if you use external libraries that implement the whole idea of classes in lua, it still doesn't feel quite right to me. So I'm starting to wonder - maybe OOP isn't the best idea for LÖVE? (Or maybe I'm just exaggerating my needs, and tables ARE all that I need?)

How do YOU people go around making games in LÖVE? What design principles do you use?

Lua is able to implement OOP but it's implementation differs from java. On my current project I am not using any OO framework at all. I use a low-level way similiar to this: http://lua-users.org/wiki/ObjectOrientationTutorial and that's all.
There is no good way to implement a game without some abstractions and encapsulation of data but in one-man projects you don't have the need to be too strict about implementation details as you should know best how not to violate your own implementation.

I found out for myself that progressing fast in your projects is way more valuable than having to deal with details of OOP or the language used. And this is exactly why lua+love is a perfect combination. What I recommend is that you shouldn't waste too much time with the details of OOP and just start implementing.

Hi meffcio!

That's an interesting question, I don't think there's a single answer out there!

Firstly, while it's great that you've got a good grounding in one coding style (OOP), you should remember that specifically what you know is Java OOP. Now I haven't used Java in a loooong time, but I don't think it even supports operator overloading (... checks wikipedia... nope, it still doesn't!), which is a really neat feature for OOP. And guess what? Lua does Well, mostly - not as much as c++, but a lot more than Java.

If you want to start with an OOP approach in LÖVE/Lua, there are plenty of libraries to do that - personally I like 30log but there are plenty of others, and it's easy enough to roll your own.

I actually toyed with an idea a while ago - write a simple game, like... pacman or asteroids or something, exact same game but written (with LÖVE) in several different coding styles - classic OOP, ECS, functional (as near as possible), c-style, event-based, etc. And then once you've got the baseline done, add individual features - to ALL versions - and see which is more flexible, more performant, etc.

when I'm writing any code I'm always thinking in OOP. I always prefer to have my model and presentation decoupled

These are two very different statements - OOP does not imply decoupling of model and presentation, nor vice-versa!

It's entirely possible to keep model/presentation completely separate using any coding style you like - a well-designed ECS should do this too, but even a simple c-like system of data structures and global functions could also separate the concepts neatly, and a (perfectly valid) OOP solution might not. For example you might have a class "Asteroid" and another "EnemyShip" which both inherit from "AiEntity" which inherits from "GameEntity" - but the code for each one could easily have graphics, sound, state, model and anything else mixed in.

I'd suggest just jumping in, code first and refactor later. There's nothing inherently wrong with OOP (although it does have its issues - diamond inheritance and all that), but it's not the only good coding style out there.

And, if I'm totally honest, strict coding styles are for workplaces. At work, I'm very strict on how the code my team writes is designed, structured and how it communicates with other areas. At home, when I'm doing personal projects, I enjoy trying new things, new structures, new ways of organising code. It doesn't always work, but those ones teach you as much if not more than the ones that do. HAVE FUN!