Predicates and Special Cases in Game Programming

[Shemar]

I may be very wrong here, but I think it is possible to restrict the special cases that apply to any single method before method invocation (at least if I create the predicates smartly enough) and what is the optimal order to test them. This means that the rules should run as quickly (asymptotically speaking) as if they were written by hand. There will be an overhead for all methods, but this may be set off by the fact that rule calculation is hardly as costly as other parts of the game, such as graphics or sound.

I am not sure how exactly you imagine it, but if yout pool of predicates is global, then no you will have to run through all of them. Of course you can have a list of attack predicates, a list of detection/stealth ones, a list of damage ones etc so you will only have to run through the relevant ones, but that is nowhere near as efficient as only testing for those that specifically apply to the given objects by linking them directly to these objects.

By the way, I don`t think that multiple inheritance alone can solve the problem. Well, it can solve a lot of the rules, but a few predicates aren't inherent about the object, just circumstantial. Stuff like "are you over forested terrain" or "is this an important battle". So, these would need to still be checked separated in each function.

This is usually solved by adding these characteristicts to an encounter type class, a pointer to which you can also pass as a parameter, so any conditions that are global to the specific battle can also be taken into account.

By the way, I have about the C++ multiple inheritance. Do I need to declare each possible combination of classes in the source code, or is it possible to create them dynamically? Like, if I have a Dwarf class and a warrior class and I want to create a warrior dwarf, do I need to create a class that inherits from both by hand? I think I read about a way using generics to create the class on the spot, but I think they still needed to be created during compile time.

Class inheritance is hard coded... sort of. This is where function pointers come in. The attack function for example can be just a pointer to a function passed on to every specific object, not the entire class. The result is that you can choose from a (possibly expandable via plugins) library af attack functions to assign to a newely created object at run time (or during level design via a toolset for the game).

 

[SCO]

I am not sure how exactly you imagine it, but if yout pool of predicates is global, then no you will have to run through all of them. Of course you can have a list of attack predicates, a list of detection/stealth ones, a list of damage ones etc so you will only have to run through the relevant ones, but that is nowhere near as efficient as only testing for those that specifically apply to the given objects by linking them directly to these objects.

One of the reason prolog is not more popular (the other is that programmers are conservative as hell, and prolog is kinda alien at first).

There are some other object models, some typed, some not, some in between.

Duck "typing", nominal typing (C++, java), structural typing (eehhh. Scala?), variations of these with contracts on top etc.

 

[Shemar]

One of the reason prolog is not more popular (the other is that programmers are conservative as hell, and prolog is kinda alien at first).

Yeah, I could never get confortable with it. It requires a different kind of thinking and problem solving approach (what you call 'alien'). I imagine it would be a whole lot easier for someone to get into it if they have never used a 'traditional' language.

 

[SCO]

Not as bad as the structural typed Haskell. It's really cool in prolog how there is no defined return & arguments, but values that can be returned (either one or more depends on the function and the defined values).

 

[Flatlander]

I may be very wrong here, but I think it is possible to restrict the special cases that apply to any single method before method invocation (at least if I create the predicates smartly enough) and what is the optimal order to test them. This means that the rules should run as quickly (asymptotically speaking) as if they were written by hand. There will be an overhead for all methods, but this may be set off by the fact that rule calculation is hardly as costly as other parts of the game, such as graphics or sound.

I am not sure how exactly you imagine it, but if yout pool of predicates is global, then no you will have to run through all of them. Of course you can have a list of attack predicates, a list of detection/stealth ones, a list of damage ones etc so you will only have to run through the relevant ones, but that is nowhere near as efficient as only testing for those that specifically apply to the given objects by linking them directly to these objects.

It depends on the systems semantics but it could very well be heavily optimized on compile time. For example, I'm sure some predicates could be statically verified to be false for certain kinds of values. With that and heavy use of caching it should be possible to achieve a good performance.

Depending on the game it might work fine even without complex optimizations and AFAIK even modern Prolog compilers are fairly good these days.

Not as bad as the structural typed Haskell. It's really cool in prolog how there is no defined return & arguments, but values that can be returned (either one or more depends on the function and the defined values).

Haskell isn't structurally typed, maybe you were thinking of Ocaml?

 

[SCO]

Ok, it isn't. However, any functional language with higher order functions always seemed more than a little bit "structural" to me.

Besides that, Haskell typeclasses abstraction over types and operations can't be actually instantiated (no function can return a typeclass, only types that implement a typeclass, since they are not types. I think of them like a implementation only interface) so haskell "O.O" is weird enough by itself.

 

[Flatlander]

Yeah, interfaces are probably the closest equivalent to type classes in mainstream languages. And I wouldn't use the term OO anywhere near Haskell, maybe polymorphism would be better term.

People tend to see OOness in everything even though the concepts (polymorphism, data hiding, message passing etc.) exists (and have existed) in some form in lots of non OO languages. Bit like everything with higher order functions is labeled functional these days.