Object Orientation is not primarily a language feature. It is a programming paradigm/method/style. That is, you can write perfectly object oriented code in pure C, and you can just as well write perfectly non-object oriented code in Java.
Object Orientation is not a virtue in itself. It is helpful most of the time, and thus rightly encouraged heavily, but there are use cases where a non-object oriented solution works just as well or better.
There is no problem with mixing object oriented and non-object oriented code in the same project. Object oriented code can call non-object oriented code and vice-versa.
The only problem that may come up is mixing code written in different languages. But, as Doc Brown rightly notes in the comments, Objective-C is a strict superset of C, which means that you can just compile any C code as Objective-C. This is very different from trying to compile C code as C++ code, which will force changes in many places. But that is not your problem, you can easily switch from a
.c suffix to a
.m suffix wherever you need it without breaking the code in the file.
That said, your main focus when refactoring your game should be to simplify your code. If you know object orientation well, simplifying your code will likely mean making it heavily object oriented. If you don't know how to use object orientation well yet, try to find at least two different object oriented solutions for each problem, and try to choose the better one in each case. But don't try to keep object oriented and non-object oriented code separate.
char* problem: I would suggest that you read up on string interning and try to implement it in your game. Because, once you have interned strings, you can simply compare your strings by comparing their pointer. That should allow you to reduce the
enum usage in a flexible and performant way.