What is your preffered way of creating games in LÖVE?

General discussion about LÖVE, Lua, game development, puns, and unicorns.
Post Reply
User avatar
meffcio
Prole
Posts: 7
Joined: Thu May 07, 2015 7:30 pm

What is your preffered way of creating games in LÖVE?

Post by meffcio » Sun Sep 16, 2018 9:41 pm

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?

daviel
Prole
Posts: 13
Joined: Tue Apr 17, 2018 5:10 pm

Re: What is your preffered way of creating games in LÖVE?

Post by daviel » Mon Sep 17, 2018 7:07 am

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. :)

User avatar
NotARaptor
Citizen
Posts: 59
Joined: Thu Feb 22, 2018 3:15 pm

Re: What is your preffered way of creating games in LÖVE?

Post by NotARaptor » Mon Sep 17, 2018 9:09 am

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!

Post Reply

Who is online

Users browsing this forum: No registered users and 3 guests