LÖVE

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?

Hello.
There's a lot of files to go through, but I think I found a small bug: Should be: Assuming that by "adjacent" you mean one of the 8 tiles around "self.x, self.y".

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.

Seriously no more comments?

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.

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.

That's a piece of great advice. Have a cookie!