pedantic object oriented question

[requerent]

Disregarding your experience/goals, Yea- I recommend a Database with no member methods/functions, with stateless routines acting on said database as an FSM of Systems.

The trouble is, with this particular project, to switch to such a radically different conceptualization would pretty much require throwing away all work done so far and starting over from scratch -- and I don't have any experience with the kind of architecture you describe. I suppose I could try it as part of a new project, though. What did you mean when you said "try something a little uncomfortable"? Did you mean "try something new so as to learn how to do it", and the "uncomfortable" bit is because you'd be starting without any previous experience with that new something?

I'd save it for a pet project if you're curious. It's my personal recommendation, but it won't be what is best for you (most people don't program this way, so there aren't many good references for it). You might try encapsulating a few of the ideas into what you already have-- breaking the logic of your game into component-systems is a very good idea whether you are OOP or DOP.

[mike3]

Disregarding your experience/goals, Yea- I recommend a Database with no member methods/functions, with stateless routines acting on said database as an FSM of Systems.

The trouble is, with this particular project, to switch to such a radically different conceptualization would pretty much require throwing away all work done so far and starting over from scratch -- and I don't have any experience with the kind of architecture you describe. I suppose I could try it as part of a new project, though. What did you mean when you said "try something a little uncomfortable"? Did you mean "try something new so as to learn how to do it", and the "uncomfortable" bit is because you'd be starting without any previous experience with that new something?

I'd save it for a pet project if you're curious. It's my personal recommendation, but it won't be what is best for you (most people don't program this way, so there aren't many good references for it). You might try encapsulating a few of the ideas into what you already have-- breaking the logic of your game into component-systems is a very good idea whether you are OOP or DOP.

Sounds good. Thanks!

[Krenium]

Hmm. I'm curious: if the critter object doesn't know its map, then what do you do with something as basic as this: movement. Suppose your "Critter" object has a "move()" method, which, well, makes the critter move. Seems reasonable, no? But then you have to check for walls, etc. (you don't want your critter to move through the walls (unless it's a ghost or something)!) which means you need access to the map. Plus, if the map contains a reference to the critter attached to the tile it's standing on, that needs updating. So what should one do? What should that call to "move()" do?

Also, where should the "critters" be stored, anyway? Currently, in my program I have them "owned" by the map, since they're on the map and most would be associated with a map, anyway (when you save out a map, you have to save out all critters on it). How should it be?

See, this is why I've become so disappointed with OOP over the past several years. This question comes up so often from so many different people that I simply consider it a failing of the paradigm.

The way I reckon it, it's because people try to find real-world analogs to their program architecture, where there really shouldn't be. For instance:

It seems obvious to you that a critter should have a move method. I say it's not obvious at all. If you don't want your critter object to have a reference to your world, then the world should have a move(Entity e) method that moves critters and other objects around.

It may not be intuitive to think that way in real-world terms, but it is much cleaner OO. You ask your world to move everything that needs to be moved, just like you ask your main game loop to update everything that needs updated.

Honestly there is not a language in existence that has a proper scope system, in my opinion. Almost all the problems I have with programming are caused by where to keep data and the juggling required to get those data to the proper functions. It's not a technical limitation; it's a conceptual one. I know I could throw any old system together and force it to work. The trick is whether it is intuitive to think about or not.

 Games are about the most state-based programs you can write, which only compounds the problem.

[requerent]

It may not be intuitive to think that way in real-world terms, but it is much cleaner OO. You ask your world to move everything that needs to be moved, just like you ask your main game loop to update everything that needs updated.

In OOP, an object should only modify its own data members. However, the Critter will typically be composed in the Map (Assuming that the Map is your state managing object). The Critter also needs to tell the map where to move, and the map needs to tell the Critter where it can move, and the Critter needs to look at the map to decide where to move.

No matter where you put the move method, there is an exchange of information that obfuscates the idea of what is actually managing the move.

Honestly there is not a language in existence that has a proper scope system, in my opinion. Almost all the problems I have with programming are caused by where to keep data and the juggling required to get those data to the proper functions. It's not a technical limitation; it's a conceptual one. I know I could throw any old system together and force it to work. The trick is whether it is intuitive to think about or not.

Lua works well for this IMO.

An excellent approach to making a game is to make it so that game data is acted upon only by pure functions without the use of methods.

[Ex]

I bet that if everyone puts their functions wherever they want, we'll all end up happy.

like you ask your main game loop to update everything that needs updated.

I don't have my main game loop update everything. I ask the objects to update themselves. And I don't even do it in the main game loop. The map does it.

[requerent]

I bet that if everyone puts their functions wherever they want, we'll all end up happy.

like you ask your main game loop to update everything that needs updated.

I don't have my main game loop update everything. I ask the objects to update themselves. And I don't even do it in the main game loop. The map does it.

It's a cascading hierarchy of updates.

[Ex]

I bet that if everyone puts their functions wherever they want, we'll all end up happy.

like you ask your main game loop to update everything that needs updated.

I don't have my main game loop update everything. I ask the objects to update themselves. And I don't even do it in the main game loop. The map does it.

It's a cascading hierarchy of updates.

All programming is, really. Main is called, and then main calls things, and those things call things, and those things call things, and then one day all of those return and you end up back at main and main returns. It's inescapable. Even in a multithreaded program, main initiates the threads, and the threads one day return before main returns. The whole of programming is a cascading hierarchy of updates starting at the program entry point.

[mike3]

Hmm. I'm curious: if the critter object doesn't know its map, then what do you do with something as basic as this: movement. Suppose your "Critter" object has a "move()" method, which, well, makes the critter move. Seems reasonable, no? But then you have to check for walls, etc. (you don't want your critter to move through the walls (unless it's a ghost or something)!) which means you need access to the map. Plus, if the map contains a reference to the critter attached to the tile it's standing on, that needs updating. So what should one do? What should that call to "move()" do?
...

In that particular design the move() method should be in the map rather than the critter because the map is the only object with the required context to actually perform the operation. The only way the critter could really know how to move is by accessing the map anyway (by a cached map reference in the critter or the map being passed as an argument to an update() method).

This doesn't occur to a lot of people because standard teaching of OOP is just hideously bad. The focus on the intuitive real world concept of objects just leads to tears in the end. Intuitively it feels like the move() method should be on the critter because critters move but that's not how you should decide where methods live.

Because a critter can't stand in the same cell as other critters you need more contextual information about how to perform the action (i.e. where the other critters are). Also a move can fail for reasons beyond a critter being in the way, e.g. lava, walls. The only place where all the data is at hand is the map object, so move() should go there.

I'm resurrecting this thread, because I want to come back to this point as I've noticed something else here: doors require access to the map too, to open and close, since they need to check if they're blocked. So now it seems the map would acquire an open/close method for doors as well. It seems the map is gaining more and more responsibilities to make up for the lack of a reverse reference... violating the one-responsibility principle. Isn't that bad?

[george]

There are two ways the critter can know about the map (well, three, but let's exclude global variables for the moment). It can have a reference to the map, or you can pass it the map. You seem to think the first way is the only way to do it, but there's nothing wrong with the second, and IMO it's a better idea than the reference.

[mike3]

There are two ways the critter can know about the map (well, three, but let's exclude global variables for the moment). It can have a reference to the map, or you can pass it the map. You seem to think the first way is the only way to do it, but there's nothing wrong with the second, and IMO it's a better idea than the reference.

Actually, I had considered such a possibility. But I wasn't sure how to make it work here. When a door is opened/closed, it is passed an event from the event queue, which it handles to open/close. Not sure whether it'd be a good idea to pass a map in the event object. I suppose it'd be OK, though, but one has to be sure not to send the wrong map. I guess that would be my concern, that such would be bug-prone.

[mike3]

Never mind. I decided to implement it anyway. You can't expect to make something "impossible" to break if it isn't used correctly...

[george]

Well I don't know how you've written your event system, but I can see a potential problem. If event 1 modifies the map but event 2 has an old copy of the map, it might be working with old data. What does your event loop look like?

[mike3]

Well I don't know how you've written your event system, but I can see a potential problem. If event 1 modifies the map but event 2 has an old copy of the map, it might be working with old data. What does your event loop look like?

There's a priority queue, ordered by logical time. The most recent event is fetched, handled, and then the time remaining on the other events is decreased, and the new most-recent event is handled next, and so forth. There is only one map in use at any time (that is, the map the player is on), and I was just thinking of passing a reference/pointer to the map. Copying the map over and over sounds like it'd make for huge overheads anyways.

[Krice]

It's extremely important to avoid any kind of copying unless it's practical.