Check for collision in mainline code or object code?

[digsy]

I'm trying to make a simple game where objects appear on the screen, you click them and they disappear. Just something to help me learn.

I have it working but my question is, do I check to see if I've clicked the enemy inside a function in the enemy object? Or just in my main.lua? Currently I have this code in my main.lua:

Code: Select all

function love.mousepressed(x, y, button)
   if button == "l" then
		for i,b in ipairs(bugs) do
			if b:isClicked(x, y) then
				table.remove(bugs, i)
			end
		end
   end
end

Which works just great. Is this a suggested way of doing this or should this code be a part of the enemy class?

Thanks.

[ivan]

Your question is trickier than you may think.
The short answer is, if your project is small then it doesn't matter too much.
If your project is big then it can be complicated. Allow me to explain.
Suppose your project has 50-60 lua files plus additional 200-300 script files with in-game content.
You want to change how collisions work, so now you're going to be juggling and editing 7-8 files at the same time.
That's why it's usually recommended to layer your code into different 'domains' which are not 'coupled' to each other.
What this means is, for example, you can have a module for physics, another module for input, a third module for GUI and so on.
When your code is split into different domains, then it becomes a bit easier to manage code and figure out where it should go.
For example:
"function love.mousepressed" looks like a function in the domain of 'input' - your input code probably shouldn't know anything about collisions.
But again, for practical purposes this is only a concern for large projects.

[digsy]

Thanks Ivan, that makes sense.

Do you know anywhere where I could read into this in more detail? Wouldn't have to be Love2d specific. I just want to get an idea of how to design my code in a clean way that will allow me to avoid complications down the road.

Thanks

[kikito]

I just want to get an idea of how to design my code in a clean way that will allow me to avoid complications down the road.

Depending on who you ask, that is the Most Important Thing a Program Should Do. To them, being able to modify things easily in the future is more important than that it "works". (Because if you are able to modify it easily, you should be able to modify it so "it works").

It is also a bit like the Holy Grail of programming - because most of the time you don't know what waits "down the road", you can not really prepare the code in advance. You always find something that you didn't foresee.

So the first thing to do is accepting that complications will happen. Not everything is lost, however; you can't avoid them, but you can minimize their impact, which is nice.

There are lots resources on how to achieve this, but this greatly enters the realm of personal preference, and intense religious battles on internet forums.

Here are my favorite non-free resources:

• The Clean Code Book
• The Clean Coders videos
• Kent Beck's Refactoring

Here are some of my favorite free resources:

• Ruby - after 1 year programming on this language, your code will just be more prepared for the future - even if it's not Ruby!
• stackoverflow.com - If you are not sure about how to implement something, ask here. If you invest a bit of time in the question, you will get a very good answer in very little time.
• The 5 letters of SOLID

Those are for programming in general. For games, Chris Hargrove's Code on The Cob, Part 1 (Especially the bit right after "Pandora's Boxes") describes the gist of it: basically, make sure that your code is "isolated in closed boxes" with as little as possible "communication" happening between them as possible (That's a mixture of S and O of SOLID).

Regards!