Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (757)
Games in Android Showcase (229)
games submitted by our members
Games in WIP (844)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Dependency Injection  (Read 1772 times)
0 Members and 1 Guest are viewing this topic.
Offline LunaticEdit

Senior Devvie

Medals: 8
Projects: 1

« Posted 2013-01-01 17:38:14 »

So, is anyone here familiar with dependency injection? I have a technical issue I'm trying to solve in my game of which DI seems to be the only clean way to deal with it. Basically I'm trying to make the attacker/victim logic completely self-contained so that I don't have to duplicate logic to each and every attackable thing in the game. The problem is there's three branches I'm current working with class-wise:

IActor -> Player
IActor -> NPC -> OldMan
IEnemy -> Crab
IEnemy -> EvilGirl

Player is going to have 'attacking' abilities, but oldman is not. But i also want to share the same logic with IEnemy as well.. So the ONLY thing I can think is to create an IAttackableActor interface which defines what I need to do my processing (getters/setters for certain things like health and defense, death, etc), then implement that interface on Player, Crab, and EvilGirl. That allow me to do this:

public class AttackLogic {
    public static void Attack(final IAttackableActor attacker, final IAttackableActor victim) {

        // Do not process attacks on a victim that is currently being staggered
        if (victim.getStaggered()) {

        // Determine the damage that will be dealt
        final int damageToDeal =
                    // This is a bit anal, but make sure damage is never greater than total health.
                    // At least 1 damage must take place
                    Math.max(1, attacker.getAttackStrength() - victim.getAttackDefense())

        // Apply damage to the victim
        victim.setHealth(victim.getHealth() - damageToDeal);

        if (victim.getHealth() > 0) {


Any thoughts on this, or if someone has a better idea on how to cleanly implement this?

Offline sproingie

JGO Kernel

Medals: 202

« Reply #1 - Posted 2013-01-01 18:27:14 »

DI is all about runtime selection of implementations, but the type system has to be set up beforehand so you could do it all without DI if you need to (and when unit testing that's usually what you do).  Statically trying to enforce a particular character's behavior (OldMan's pacifism) through the type system is really just not feasible.  The typical answer for most RPGs would be that you just allow OldMan to inherit an attack capability through IActor that does no damage, and then just never use it. 

PS: Not a fan of that "I" prefix for interfaces BTW, but hey it's your thing
Offline LunaticEdit

Senior Devvie

Medals: 8
Projects: 1

« Reply #2 - Posted 2013-01-01 18:42:43 »

PS: Not a fan of that "I" prefix for interfaces BTW, but hey it's your thing

I did it here just to imply that I'm passing in an interface - I don't use them either. I hate decorations on types.

I've spent the last hour removing all attack logic from player and enemy (VERY different types of entities) and trying to stuff it into an interface/processor type setup (i guess that's the right word). There's a little bit of overhead of course, but the main goal is separation of intent. Most of the game is already logically separated into interlocking and stackable parts. I initially thought about making Actor and Enemy subclass from something else, but the problem is that down the road, there will be more 'services' applied to the characters in the game (smart movement, npc to npc interaction, etc). It's a mixed bag which actors/enemies implement which services, so the fixed hierarchy didn't seem to fit. The only annoying thing is that since it seems I need to do attacking this way, I'm going to have to roll back some of my other logic to use the same methodology -- I don't want to have two design patterns in the same class, that'd be very annoying. *sighs*

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline sproingie

JGO Kernel

Medals: 202

« Reply #3 - Posted 2013-01-01 22:20:06 »

I suppose you could take the capabilities approach and delegate actions to Action objects, with each entity maintaining a set of actions it can take.  A NPC that will never attack could simply lack an AttackAction altogether then. 

If you're still keen on using DI, and combat is central to your game, you could have an attackAction field rather than one big collection of actions, and use DI to inject appropriate instances of AttackAction.  But much as I like DI myself, I don't think it would be very satisfying for defining available actions in general.
Pages: [1]
  ignore  |  Print  

EgonOlsen (45 views)
2018-06-10 19:43:48

EgonOlsen (25 views)
2018-06-10 19:43:44

EgonOlsen (47 views)
2018-06-10 19:43:20

DesertCoockie (202 views)
2018-05-13 18:23:11

nelsongames (127 views)
2018-04-24 18:15:36

nelsongames (126 views)
2018-04-24 18:14:32

ivj94 (867 views)
2018-03-24 14:47:39

ivj94 (128 views)
2018-03-24 14:46:31

ivj94 (771 views)
2018-03-24 14:43:53

Solater (143 views)
2018-03-17 05:04:08
Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39

Java Gaming Resources
by philfrei
2017-12-05 19:36:10

Java Gaming Resources
by philfrei
2017-12-05 19:33:10

List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05 is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!