Effective character/enemy programming

Aug 12, 2014 at 6:50 PM
The Preacher
"Wacka-Wacka-Wacka-Wacka-Wacka-Wacka-Wacka-Wacka-BLEIUP"
Join Date: Feb 20, 2011
Location: lost in translation
Posts: 336
Age: 31
I use actual threads, because in my solution the frequency at which the state of the game is updating isn't necessarily the same as its framerate. I chose to do this because if someone has a slow computer (or forcibly slows it down), the game won't actually go slower, the framerate will just drop. This is to prevent cheating through slow-motion, as can be done in The Binding of Isaac for example.
 
Aug 13, 2014 at 3:42 PM
Senior Member
"Wahoo! Upgrade!"
Join Date: Aug 11, 2014
Location:
Posts: 57
So last night I put on my magical imagination cap and pretended to be a software engineer. I did in fact open that book that I haven't touched for 3 years and unfortunately it was mostly about refactoring, not so much patterns. I did however, start scavenging on wikipedia and found some very interesting things.

It seems that FSM proposal we dreamed up is a combination of 3 patterns:

1) Dependency injection

2) Service Locator Pattern

and 3).... get ready for it, its the most unintuitive name ever....

the State Pattern

I know right? What nutball thought of that name?

Anyway, I knew the State Pattern was a thing, but what I didn't know is that algorithms encapsulated in other objects was a core feature of it. I'll go through and explain how each of these patterns applies here. To any readers, don't take what I say as a fact or anything because I am certainly not an expert, but here goes:

Dependency Injection is just a fancy way of saying that an object is given it's state variables rather than creating them. We create algorithm objects and give them the components they need to operate, and that's really all there is to it.

State Pattern is the obvious one here. The defining feature is that you write these abstract algorithms and then the using object gets assigned one service at a time that it then delegates its responsibilities to. I think this is very similar to the delegation pattern that Noxid mentioned, though if I understand correctly, delegation pattern is just sort of an umbrella term for breaking up class responsibilities. Wikipedia had some cool diagrams of the state pattern:

p187018-0-wdlemqn.png


p187018-1-om3vxsg.gif


The Service Locator pattern is one im not totally sure about. The pattern states that the core idea is that objects have their services (algorithms) chosen for them instead of choosing themselves. While the fsm is part of the class in question, and it declares all its needed algorithms up front, it still does not directly choose the algorithm its running, and therefore I think this still falls under this pattern description. If someone has a better alternative im all ears.

So it's good to know that the solution isn't totally out of left field and has some basis in practice. I'm still struggling with a good way to make this fit into my overall program architecture so far...
 
Top