## Making a roguelike game - please review my OOP code

Questions about the LÖVE API, installing LÖVE and other support related questions go here.
Forum rules
meffcio
Prole
Posts: 7
Joined: Thu May 07, 2015 7:30 pm

### Making a roguelike game - please review my OOP code

Hi guys, my 1st thread on this board.

I'm making a classic ordinary roguelike game in our beloved framework and as always I'm having a hard time designing the logic. The code's on github. I'd like to ask you guys to tell me what you think of what I'm doing. Basically I'm pretty sure I'm making it too complicated, but here's a little resume.

MapGenerator is going to be based on the one from TinyKeep. It now uses a class called Room (that has an origin point, width and height), probably I'll also create a Corridor class. (I'd prefer not to) Eventually the generator is going to convert Rooms (and Corridors) to a table of Tile objects, each having it's position, a reference to it's graphic representation (or maybe not - maybe I shall move this to a MapRenderer and get the image based on tile's name or an enum?) and attributes like isSolid etc. There's also a MapEntity class that's going to be used by objects such as treasure chests and doors, and of course the Actor class derived from by Hero and Monster classes. I'm thinking of making also a Player and AIPlayer classes which would hold references to actors, but that seems to be only doubling the code - those functionalities can basically be put in Hero and Monster classes.

So what do you guys think? The code's a mess for now, I'll clean it up a bit when I get my mind right.

Also, a question - shall I expect any problems using SpriteBatches along hump.camera module?

ivan
Party member
Posts: 1561
Joined: Fri Mar 07, 2008 1:39 pm
Contact:

### Re: Making a roguelike game - please review my OOP code

Hello.
There's a lot of files to go through, but I think I found a small bug:

Code: Select all

function Position:isAdjacent(position)
if position.x == ( self.x + 1 or self.x - 1) then
return true
elseif position.y == ( self.y + 1 or self.y - 1) then
return true
else
return false
end
end
Should be:

Code: Select all

function Position:isAdjacent(position)
local x1, y1 = position.x, position.y
local x2, y2 = self.x, self.y
if x1 ~= x2 - 1 or x1 ~= x2 + 1 then
return false
elseif y1 ~= y2 - 1 or y1 ~= y2 + 1 then
return false
else
return true
end
end
Assuming that by "adjacent" you mean one of the 8 tiles around "self.x, self.y".

meffcio
Prole
Posts: 7
Joined: Thu May 07, 2015 7:30 pm

### Re: Making a roguelike game - please review my OOP code

Thanks for pointing that out, but as I said - the code itself is low priority for now. I'd like to have some guidance in oop design of the game logic.

meffcio
Prole
Posts: 7
Joined: Thu May 07, 2015 7:30 pm

### Re: Making a roguelike game - please review my OOP code

Inny
Party member
Posts: 652
Joined: Fri Jan 30, 2009 3:41 am
Location: New York

### Re: Making a roguelike game - please review my OOP code

I took a quick peek, it seems fine, though it looks like you need to invert the way in which you're building the code. You're doing whats known as a top-down design, where you're stubbing out all the classes you think you'll need with the intention of filling them in later. Instead, it'll be more satisfying to design bottom-up, as in start with something playable. Write enough code to just walk around. Then enough to have walls that impede your movement. Then have other things moving around as well. Then have it so when you touch one it might remove it from the level or not based on an HP variable decreasing. The OOP design is there to ultimately serve your needs, you shouldn't be serving it.

meffcio
Prole
Posts: 7
Joined: Thu May 07, 2015 7:30 pm

### Re: Making a roguelike game - please review my OOP code

Inny wrote:I took a quick peek, it seems fine, though it looks like you need to invert the way in which you're building the code. You're doing whats known as a top-down design, where you're stubbing out all the classes you think you'll need with the intention of filling them in later. Instead, it'll be more satisfying to design bottom-up, as in start with something playable. Write enough code to just walk around. Then enough to have walls that impede your movement. Then have other things moving around as well. Then have it so when you touch one it might remove it from the level or not based on an HP variable decreasing. The OOP design is there to ultimately serve your needs, you shouldn't be serving it.