Was the #define really necessary?

Yeah that's what I was thinking.

Stephen001 wrote:

...

A form of SoC applied to a combat system would make a very nice article here. In the old BYONDBwicki, Iain(P) actually had a decent page about it... I wanted to link it here but couldn't get a hold of it. Should write a new one. Since I haven't done anything BYOND-related in ages maybe I'll do it, if you don't mind.

I like that you suggest using an attack proc so that AI and player attacks are handled the same way.

Some people mentioned consolidating the NPC and Enemy variables. I agree that it's not incorrect, but for the example you might want to get rod of them entirely (or only mention them at the very end). Players, enemies, and NPCs can have very complex relationships, but that's not the focus of your article. Any mention of that is a bonus.


I don't think the problem with the basic combat system you presented was the lack of realism, but the lack of fun. Combat should be the most interesting and most fun part of many games. Mashing a button isn't much fun whether you have to face your target or not.

A note to others, "modular programming" and "separation of concerns" are both buzzwords. It doesn't matter what term you throw around, it matters what you're saying. GhostAnime didn't need to throw out any buzzwords, he provided an example of why having a proc to inflict damage is a good thing. You don't need to explain how it "separates concerns", technical people can see that the code is much simpler without the buzzwords.

You can show people an easier way to do things, but they might still prefer their way of doing things. I'd have taken it a step further to show how your way can easily accommodate new things while their method cannot. Following this example, a player might use an ability that reduces their damage taken by 50%. If you have 15 abilities in your game, each one manually subtracting from the mob's health, you have to add this change in 15 different places. If you instead use the same proc to inflict damage in all 15 abilities you only need to make this change in one place.


A game should have more than just a single "attack" command. Implementing as many skills as you might like to have can be difficult without using object-oriented programming. Abilities have many things in common. Showing how object-oriented concepts can be used to implement a variety of abilities would make for a good article.

You could show how having separate verbs for separate attacks* ends up having a lot of repeated code (check if the ability is on cooldown, find a target, check if the player has enough energy/mp/mana/whatever, subtract the cost of the ability, calculate the damage done, inflict this amount of damage, show a graphical effect, etc.). Using inheritance and abstraction you can really cut down on the amount of repeated code which makes it easier to add more abilities, which ultimately makes games more fun.

* This is why you don't throw buzzwords around. For every good way to "separate concerns" there are a thousand bad ones.

Forum_account wrote:

A game should have more than just a single "attack" command. Implementing as many skills as you might like to have can be difficult without using object-oriented programming. Abilities have many things in common. Showing how object-oriented concepts can be used to implement a variety of abilities would make for a good article.

You could show how having separate verbs for separate attacks* ends up having a lot of repeated code (check if the ability is on cooldown, find a target, check if the player has enough energy/mp/mana/whatever, subtract the cost of the ability, calculate the damage done, inflict this amount of damage, show a graphical effect, etc.). Using inheritance and abstraction you can really cut down on the amount of repeated code which makes it easier to add more abilities, which ultimately makes games more fun.

This is what I had in mind for an article, actually. As you said, and I wholly agree, call it separation of concerns, modular programming and whatnot; what's important is how clear you were about what aspect of the code you want to improve (I was thinking "organizing by functionality" is a good name in this particular case). The two terms have long lost their original definition.

That said, Forum_acc, Stephen was saying separation of concerns is simply the more useful term here because it yields more practical search results. I don't think he was advocating one term in favor of another for reasons of inherent meaning.

The buzzword, separation of concerns, is a technique that people can use to organize their code. When you're talking about how to use the technique you don't need to explain what it is, but you do need to explain how to apply it.

You would never look at someone's code and say, "oh, you should use some separation of concerns there" because the meaning of that statement is never clear. It would be like if someone asked you for directions and you said, "you should use the principle of Driving a Car." Clearly they should drive, but how? where? on what roads?

If you're going to have to explain what you mean you'll end up not needing the buzzword. Terms like that exist, supposedly, so that we can discuss things at a higher level. SoC is just a newer sounding term for some parts of OOP. Those parts already have names so we don't need the new term.

Separation of concerns as a software concept predates OO as a paradigm, as Dijkstra was the first famous user of the term as far as programming goes, back in 1967.

If you're going to push the term, check your facts. Dijkstra first used the term in an EWD from 1974, not 1967. Read the paper too, his definition is far from yours - the term didn't always have its modern-day meaning (who knows when it took on this meaning). People have been doing OO-like things since the early 60s. OO languages started appearing in the late 60s, early 70s.

The term is a buzzword because it isn't needed. If you're going to talk about how to apply the concept you'll talk about abstraction, encapsulation, and other well-defined ideas. These well-defined ideas came first. It's not like the idea of "separating concerns" was proposed and that led to the development of inheritance. The ideas it represents were already defined so there is no technical need for the term.

Software engineering is a field that lots of people are trying to profit from by writing awful books. There are lots of books about object-oriented programming, lots of good ones. For another one to be successful it would have to be really good. It's a lot easier to write a bad book about the "seperation of concerns" or some other term. It's easier to write and will sell decently because people will think it's something new.

Abstraction, inheritance, and recursion aren't buzzwords. You can give examples of them, you can see them in action. Focus on those ideas and forget about the buzzwords.