Thanks for the clarification, I appreciate it. :smile: My next question is whether you think that this is really an OO-only thing? E.g., could improvements also be made without using OO design patterns, etc.

Yes

Sorry, is that yes to "this is really an OO-only thing", or yes to "could improvements also be made without using OO design patterns"?

Because spells are generally tied to objects further down the food chain, and if you bundle everything into World, you might as well just use global variables and not bother with objects at all. :)

Of course, your World object may be very different than how I envision it. To me, a World object handles things that affect the game world as a whole, and it contains collections of other objects that are part of the game world. The current time is likely to be the same for the entire game world, although day/night cycles or weather may vary by zone. The fact that the game is wizlocked, or shutting down is also something that affects the whole game world.

A spell is generally an action performed by a creature, either a player or an NPC. Even when the spell itself is cast by (bound to) an object, it's generally triggered by some action of a creature. Now, the effects of the spell may well have an impact on the world. If I cast "Power word: pain", it will likely only affect my target. If I cast "Fireball", it will affect several creatures in an area, as well as some objects. If my rooms have destructable environments, it might even affect the room. A spell like "Phandelume's Ritual of the Binding Darkness" might affect an entire zone.

So, given that, I would place the spell casting itself as a feature of the physical object class, which both creatures and items inherit. The spell effects, however, might be best managed by a seperate Spell Manager, because they can affect things outside the scope of the thing casting. Could you put that in World? Sure… but again, do you want everything in World?

Oh, and as for a Weather Manager…. that depends on how complex your weather system is. :) If you just want simple weather that keeps you from having a snow storm in one zone and a blistering drought in the next over, putting it in the Zone object and have those zones talk to their neighbors is probably enough. If you want real weather fronts that flow across the map, yeah… a Weather Manager is probably a good call.

The latter, but I have less empirical and formal knowledge on what those improvements might be. Which is why I tend to favour the OO methodologies and practices I use all the time.

I think you're confusing spell effects with spell-casting events here, but I'm not sure. You'll have to clarify what you mean by "spells are generally tied to objects further down the food chain." Spells in my game can be cast by just about anything… including the World itself.


I have effects as a collection on the root class, which everything inherits from. These are wholly separate from Spells, and from where the logic for spell-casting should go, though. Question: in your hypothetical system, are you assuming that spell-casting logic would be a part of the actual Spell class? It's not clear to me from reading your comments.

Listen, it seems to me as if you have made up your mind where you want to put your spell casting stuff. Why do you persist in questioning the advice you are given? There's nothing wrong with it initially, but it's been spelled out many times now…

There's no magic trick, there's no silver bullet.. just choose a way.

FWIW I thought Deimos's questions just now were very legitimate, important and interesting. Spells != general spell-casting process != specific spell casting rules != spell casters != effects.

Yea ok I think perhaps I over-reacted a little. Bad week, apologies.
.

Conceptually…
Spell casting belongs to the Wub, movement belongs to Utility.
Why?
Since the Wub is the source of all magic, all spell casting belongs to it.
Since movement requires the cooperation of a fairly large number of objects, it doesn't "make sense"(TM) to include it any of the objects involved so it's shoved into a Utility module.

TIMTOWTDI

Do you mean this wub?

That particular comment was a response to some of what Deimos said earlier in the thread. He has since announced that what he said and what he actually meant were two entirely different things. With regard to what he nowsays he meant (for example, in post #76) that comment is indeed not applicable.


Of course, the separation is not arbitrary. The process of determining whether or not a spell is cast successfully (as distinct from modelling the process of a successful casting) will be largely the same, regardless of which spell is being cast. Clearly it would be stupid to write a number of different classes which all do exactly the same thing, so the odds are one class will do this job for all spells.

On the other hand, checking to see whether a spell-cast is successful, and checking to see whether an attempt to walk through an exit is successful, are clearly almost entirely unrelatedthings. It therefore makes no sense to have the same class handle both.

The practical problems you get from having a class that does far too much are partly that you may get unforeseen interactions between different parts of the code, but mostly just to do with ease of maintenance. It makes the code far easier to read; it makes it far easier to understand what it is doing; it makes it easier to debug; it makes it easier to find the section of code you're looking for.

To make a non-code analogy, if you are looking at ways to file documents in box-files, it probably doesn't make sense to have every single document in its own seperate file; but unless you have only a very small number of documents, it probably also doesn't make sense to put every single document you have in one box, all jumbled up together. If you can understand why that is true, then you can understand why it is not a good idea to file every single piece of code in the game under "World".

This seems rather over the top to me. Input and output are also two unrelated things. Should I partition my Server class into InputManager and OutputManager or the like? Should my Engine class have a SignalManager because catching interrupts has nothing to do with running the game? There's a million and one examples like this in a typical game. I find it hard to believe that even your projects have a class for every "unrelated thing" :tongue:


You're using hyperbole here to emphasize your point, but surely you realize that I'm not advocating that every single piece of code in the game go under World. A more accurate analogy would be having a very organized system of folders for your documents and trying to figure out whether these 2-3 files should go in the World folder or whether you should make new folders for each of them.

No analogy of coding or software will ever hold up to large amounts of scrutiny.

The more I read your posts deimos the more I think you actually do understand the concepts being given here, and I cannot work out if this is a very clever troll or not.

However, giving you the benefit of the doubt one more time, it's like this:

You're building a house say. You're building it from the inside, and you are also living in it. You're building it a brick at a time, from the foundations up. At some point in time you put in the plumbing, wiring and so on: the utilities. Those utilities run other thing in your house, the toilets, the lights and so on. Logically and conceptually you do not want those two things to interact with each other so you protect the wires and ground the pipes. Eventually you build some rooms, and plan to put the tv in one room, make another a bathroom and so on. You don't put the toilet in the living room because conceptually it does not belong there. You also do not put a bath in the kitchen because, again, that's unconventional. Neither do you bury the lights in the foundations or put the fireplace in the garage.

That's not to say any of those things are 'wrong' btw, some might be dangerous of course or impractical.

And nothing in that analogy will surprise you I guess, all good common sense, but that's cause you live in some kind of house and are familiar with those conventions. The reason I guess you cannot see (perhaps) the metaphorical problems of the analogous 'toilet in the living room' yet could be lack of experience or guidance or both; but trust me, every time you take a sh*t in your living room after you've built it that way you'll understand. And then you'll move it.

I would have to know a lot more about your implementation to give you a definitive answer to that, but based on educated guesswork I would say the answer to both of those questions is probably "yes".


I think a slightly better analogy would be "every time you get an electric shock climbing into the bath because you haven't adequately separated the wiring and the plumbing".

:smile:

Well, yes, but then not everything you have problems with will be dangerous.

However most thing you do badly will definitely stink…

And you most certainly don't put the shower in the same room as the toilet, because conceptually "it doesn't belong there" either. No, it belongs in the ShowManager room, wholly separate from the ToiletManager room and the SinkManager room, because these are distinctly unrelated things.

Or are they?

I think that Deimos does understand, and simply disagrees. Flumpy, your comments leave room for error, personal experience, preference, circumstances and the like, whereas Shasarak is making far more absolute claims leaving no room for doubt. I think it's fair to simply disagree with such claims, while still questioning them some more just in case there is some additional insight to be had.

For example, one can just as easily separate different functions into namespaces or even files rather than classes, and achieve the exact same organizational benefit (let's assume that Shasarak is correct that one must obtain this benefit) whereas Shasarak only sees this through objects.

Indeed, a singleton class is really nothing more than a namespace. Some languages have no notion of namespaces, and force you to use singletons or classes with only class-level methods. Every single one of these benefits:

can be achieved without classes in this instance.

All of this to say that I don't think that Deimos is trolling in the slightest. I think that he, like myself in fact, is questioning Shasarak's claims "just in case" but remains wholly unconvinced that they are as absolutely true as he seems to be saying. :smile:

You're doing it wrong again. The "manager" objects would not be in different "rooms". The manager objects are more like the plumbing and drainage in that analogy. The actual shower definitely belongs in the bathroom because it is convenient to have the other bathroom things around when you get out the shower. Some people have their own shower rooms, but you can bet your bottom dollar they still use drains and pipes and electricity, sometime connected to the rest of the house's utilities and sometimes isolated because of practical necessity.

As I said, analogies only go so far.

You can't really explain something by giving an analogy, only to back away from that analogy once it's pointed out that it's flawed. You might as well not give the analogy, if the analogy doesn't actually hold up… :thinking: