I am in the process of implementing a structure for my project. I am now getting close to the point where I start to bring the systems I have built together and build the game, and I am now looking at the GameMode. It’s a mess.
Here are some of my issues with it:
It’s huge, and from looking at the code in UEngine::LoadMap, we have to derive from it. Not cool.
It’s got a hardcoded state machine in it. I don’t want to use it. I don’t have matches. I don’t want to work around the concept of matches. I’ve got my own state machine, and I want to use that.
Since it’s in the base class that we have to derive from, I can’t easily remove this functionality.
There’s a lot of stuff in there that is vital, but it’s very hard to separate it from the stuff that isn’t since it’s all glommed together in this enormous class.
Way too many assumptions about the kind of game I am building. For instance, I am building a game that procedurally generates its levels. I will NEVER load another map, or another GameMode. I don’t want to open ports for other players to connect to by default, etc.
So, has anyone come up with good solutions to these issues? The solution on the top of the list in my mind right now is forking the engine and splitting AGameMode into a base class and another class with all the shooter gameplay code in it. I really wish I didn’t have to do that, this greatly complicates maintenance.
The other potentially simpler (maintenance wise) option is an alternate path from the UEngine level that doesn’t make the same assumptions. This would allow me to simply not touch the existing classes, except for adding some methods.
Both are a really stupid amount of work for something that I should be able to do fairly simply.
Welcome to the mud pit I’m looking at it now as well.
Looking at the API, it’s mostly virtual except for the variables, which UE4 has throughout the engine :mad: What is the issue with overriding everything and just ignoring the code in AGameMode? Splitting it up is going to impact a lot of other classes unless you keep the same API on the base class.
Yes, that’s another idea. The issue I have with that is basically having to override all these methods I’d rather delete just to tell them to not do anything. It’s ugly.
Also, most of the work the GameMode is doing, I’d rather not have it doing. I wish I had a tool to visualize just what classes are tightly coupled with GameMode, and what methods they are calling. I might have to resort to pen and paper!
The current GameMode is stored in UWorld::AuthorityGameMode. UWorlds (there can be more then one) are stored in UEngine However it’s referenced all over the place through the getter function UWord::GetAuthGameMode(). So if you want to change the API, you’re going to have a lot of work in a lot of different classes.
Yes, I was just going through all of the references to AGameMode. It’s a lot. It’s seeming more like my only feasible solution is to neuter the class. This sort of thing is really taking the bloom off the rose.
So, I’ve just done the refactor where I made a superclass for AGameMode. So far, pretty painless. There’s a few instances where engine classes are reaching into the gameplay parts of AGameMode, but I’ve got around them with a Cast<AGameMode> on the base class pointer.
I’m just now implementing my stuff to see if it works as expected, but things seem to work. It’s a pretty simple refactor, despite touching quite a few files.
I’ve got the changes in a forked UE4 repo, and when it’s obvious that it all works I will make a pull request. If anyone is interested in looking at the changes before then I’m happy to share.
Thanks James, in the process of syncing my 4.3 fork with 4.4. Being a recent Git convert, I still find it funny that what SVN would just merge without complaint, Git often calls a “conflict.”
I’m looking at it now as well.