Inheritance is probably the most overrated OO feature, and alas usually presented as the one-size-fits-all solution in most introductory OO literature. The truth is that the real main OO features are encapsulation (which is not data hiding per se, but the ability to define self-contained componants that group together state and behaviour and abstract implementation details from client code) and polymorphic dispatch (the ability to use objects from different types / with different implementation in a uniform manner by the use of a common API).
At the semantic level, inheritance describes a "is a" relationship - if B inherits from A, then B is a A (cf the liskov substitution principle). So, is your "Platform" a "Solid" or is it a "SemiSolid" ? (hint: this is of course a rethoretical question).
At the implementation level, inheritance is, mostly, a fixed (static) and somehow restricted form of composition / delegation - whatever is not implemented in the child class is delegated to its parent(s). Good OO design is based on separating responsabilites and separate invariants from variants, delegating the "variant" part to another object. This is examplified by the Strategy pattern and its close cousin the State pattern.
Chances are that the answer to your question is mostly to use the Strategy
pattern to handle the behavioral difference between solid and semisolid blocks - in which case you'd only have one single Block
class responsible of everything that's common to all kind of blocks, and strategies for the "jump thru" behaviour (and other eventual behavioral differences between blocks). Then your Platform class - which doesn't necessarily have to be Block subclass (might or not be the right design depending on the context) - would take either a "jump through" strategie as argument (if you decide to make it a Block) or a Block instance (created with the appropriate strategie) if you decide to not make it a Block subclass.
This not only solves your current problem, but also allow to add new strategies etc without touching existing code, and avoids combinatorial explosion of classes.
NB: you may want to get yourself a copy of the GOF "design patterns", not that much for the patterns catalog itself (however interesting it is), but mostly for the first (long) introductory part of the book which is so far the very best available text on proper OO design.