Comments on: Fluent Game Design With Fluent Interfaces

By: Anton

Anton — Tue, 26 Apr 2011 14:57:20 +0000

I’m kind of surprised that there has been no mention of Linq in the article and in the comments. The article is really talking about organizing your logic in sets, thus the UnitLists can easily be IEnumerables and thus Linq operations can be used instead of explicitly calling the Where methods.

Voila! Cleaner code and making the most out of your investment to C#. =)

By: Chris

Chris — Tue, 16 Feb 2010 12:12:11 +0000

Fascinating as this method is, I think I still prefer the simpler (To code, although monolithic):

ApplyDamage(5, 2, Team_Enemy, Type_Tank);

Which is easier to work with these days due to function signature tool tips.

DamageApply d;
d.SetDamage(5);
d.SetRange(2);
d.SetAffectedResctriction(Enemy);
d.SetAffectedResctriction(Tank);
d.Apply();

By: a0a

a0a — Fri, 12 Feb 2010 13:42:51 +0000

Take a look at inference engines. Basically they are rule based system that contain rules that you have to specify as you wrote here, save some syntax differences.

The thing is that our game designers ARE writing such rules, and are successful in doing so. Slightly subtle is that they are not communicating with the engine directly, which is probably why it works so well for us.

By: Matt

Matt — Sat, 06 Feb 2010 09:49:40 +0000

The standard example should read:

foreach (var unit in player.UnitsWithinRange(2)) {
if (unit.IsType(Enemy) && unit.IsType(Tank)) {
unit.Damage(5);
}
}

By: Doolwind

Doolwind — Wed, 03 Feb 2010 22:03:41 +0000

Bill-

A couple of people have said the same thing to me. I can see that it brings confusion, I’ll update my example to better fit

By: Bill

Bill — Wed, 03 Feb 2010 22:02:18 +0000

I find myself doing this kind of thing too…

But something about having And(…) and Where(…) performing the same function irks me. Those two words represent different ideas and the idea of being able to use them interchangeably (lines do get deleted, and random ones cut/copied and pasted from place to place).

Maybe something like this reads just as well, and hopefully is less error-prone:

player.UnitsWithRange(2)
.OnlyWhere(UnitType.Enemy)
.OnlyWhere(UnitType.Tank))
.DoDamage(5);

By: KStaff

KStaff — Wed, 03 Feb 2010 14:51:52 +0000

While these two examples are the same functionally, I was wondering what effect the fluent example has on complexity. I realize it’s unlikely to have a large enough number of conditions to cause a huge difference, but won’t the extra loop add some unnecessary variables to the stack? If the code has a large number of these calls, could that eventually effect the game’s efficiency? Otherwise I think this is a really interesting concept.

By: Doolwind

Doolwind — Wed, 03 Feb 2010 12:54:10 +0000

Arowx-

I completely agree. I had written up a little on DSL’s (Domain Specific Languages) but decided to leave it out so the article didn’t get too long. I might throw my thoughts in to the post tomorrow.

By: Arowx

Arowx — Wed, 03 Feb 2010 12:52:16 +0000

Its startting to look like a bit like SQL, would the next step be to create a language expressly for this purpose:

Select UnitsWithinRange 2 of player
Where isTank
Then DoDamage 5

By: Doolwind

Doolwind — Wed, 03 Feb 2010 12:31:36 +0000

Markus-

I’m glad you’ve raised some concerns about the “safety” of these interfaces over traditional interfaces. I saw it as being a much better solution, so long as good though is put in to the initial design. I definitely think a defensive stance needs to be taken to make sure this doesn’t cause more issues than it solves.