Game structure and maintaining local scope

[Reef]

First, I wasn't sure if this should go in General or Support, but it's a fairly general question so I put it here.

I've been toying with Love for a while, lurking and peeking at people's .love files but I haven't progressed much beyond that. I've started a game much like Asteroids to practice implementing interactions more complex than Pong or Breakout and start using OOP principles. One thing I've run into is how to structure my game's architecture in a way that allows me to maintain local scope as much as possible. I know this can be a matter of opinion ( see here ) but I'd like to build good habits and I can see the benefit of avoiding globals.

Regarding my current project:
How would I handle the collision of a bullet class that is used by both the player and the enemy? I've considered class and collision libraries but I'd like to understand what's going on and how things can be structured. Maybe this is all a matter of opinion and I'm over thinking things.
Should I pull the collision function out and handle it in the general game class and pass it a bunch of information each time?
Is there a way I can make all of my classes local and still have globally available info such as x and y coordinates?

I'd appreciate if someone could look at my project (specifically the shot.lua file) and give me advice or comments. Thanks!

[sashwoopwoop]

Hey,

first of all I think posting this in General is fine. I took a look at your code and it looks nice and clean, your OOP approach is totally fine. Here's a couple of things I would change:

• I would move enemy / mob creation to the game class
• I would make `enemies` a local variable in game
• I would pass a reference to you game instance to Shot, Player and Enemy. This way you can access self.game.enemies instead of the global enemies table
• I would also rename the enemies table to "mobs" so that it holds both the player and all of your enemies. Make sure you hold a separate reference to your Player instance to handle keyboard input and such.
• I would keep the collision in the Shot class, that's totally fine. But I would add an `owner` property to the Shot (which is a Player instance if the player created it or an Enemy instance if an enemy created it). Then you can simplify your collision detection by iterating over all `mobs`, checking the distance to the Shot and checking the ownership (something like `if self.owner ~= mob then ...`)

Hope that helps

[Robin]

This is more a S&D thread.

[sashwoopwoop]

This is more a S&D thread.

"General: General discussion about LÖVE, Lua, game development, puns, and unicorns."

[kikito]

How would I handle the collision of a bullet class that is used by both the player and the enemy?

That depends. Putting the collision code in the Bullet (I prefer that to Shot) class is ok if you are only going to have that type of collision. It means that "only the bullets collide with thigs".

But will there be any other things colliding between each others? For example:

• Player vs enemy
• Player vs environment
• Enemy vs environment
• Bullet vs environment

If that's the case, then "the fact that something collides with something else" is not a "property" of the bullets exclusively. It's a piece of functionality "used by several classes". And you should treat it as such - putting it on an external place where it can be used by everyone. Be it an additional function (like isColliding(a,b)), a separate class (like Solid(l,t,w,h)), a mixin (like Collidable) or an external library.

[Reef]

Sashwoopwoop: I ended up making nearly all of your suggested changes and that was exactly what I was trying to do. Passing a reference to my game instance was just what I needed to do. Now I can see how I would implement state handling and different levels.

Kikito: I looked at your Bump library for some guidance in passing reference and I'll probably spend some more time looking at it to figure out how to pull my collision handling out into it's own function or class; I'm not very familiar with mixins.

Thank you all for your help! This was exactly the advice I was hoping for and I feel like I have a much better understanding now. Hopefully I'll be able to finish this project into a game and share it with the forums!

The Support forum seems more oriented to the Love API specifically, this was a general Lua/GameDev question.

[Inny]

I remember seeing a library, Lovebird, which turned the running love instance into a web-server that could be used for externally debugging. One of the requirements was that the game's instance was kept as a global variable. I recommend it, at least from that point of view. If you design your game the was a C programmer would, then every object would be kept as a child or grandchild of the game instance. However it'd be a bad idea to store things in multiple global variable, or having anything in your code actually using the global variable.