I presume this function is declared virtual? If so, what you need is a pure virtual declaration (use " = 0" after the declaration), and no definition:
Why does everyone think the OP is using a virtual function?
He says that the function is left undefined. It's not a pattern that I like, but approaching this as if inheritance is already being used and then using this assumption to criticize the OP's poor use of inheritance doesn't make any sense.
I have to ask, where does that useSpecialNames bool is the sample code come from? What sets that? Wherever that bool is set, you might be able to just pass in a whole inventory object, or maybe an inventory object factory, to the game instead of the bool.
So now I'll make my assumptions:
I believe the OP's engine is structured in such a way that the inventory object is constructed deep within "engine" code and so inheriting from it and overriding functions is not an easy option to add: at least it wasn't as easy as this undefined function so that's what happened. I suggest, if undefined functions implemented for specific games is the only practical solution available right now, you should write up an inventory interface and replace the constructor for the inventory class with something that returns a pointer to this interface. Games that have no inventory could just return null, so only a minimal amount of boilerplate is necessary. Games that can use the default inventory can construct the existing class and return it. Games with a custom inventory can inherit from the base object for small differences or just reimplement the whole class for drastic changes.
In my opinion, I prefer an "engine" to be a collection of useful classes that can be put together into a game on the game side, so the choice of which inventory class to use or whether to even use one is squarely on the game side, not the engine side. Each game might require a little more glue code this way but it's much more flexible.