This is an IGN article about the above question posed on Twitter:
At this point in my career, I claim BINGO… I have encountered (and had trouble with) every single one of those things while working on a game… ONE HUNDRED PERCENT!
doors
elevators
platforms
movement
physics
mission / story states
text / fonts
localization
tutorials
looting
shooting
jumping
savegames
multiplayer (even couch coop!)
matchmaking
network lag
menus and UI
inventory systems
JIRA
But one thing is for sure:
Good familiarity with Unity3D and all that it has to offer can make EVERY one of the above things easier to deal with effectively.
Well, not JIRA, nothing can help make JIRA easier!
every tool works just like it should, until you try to make it work with two others. then you got to troubleshoot to figure out all the caveats that aren’t written down anywhere. I guess that might fall under “struggling with the engine.”
It’s all fun and games when everything is a bunch of disjointed systems with hordes of small issues the team became blinded to over the course of development, but it takes a good amount of buckling up to actually turn it all into a cohesive and polished product which can be played by a stranger for over one hour without glitching in some way.
In my experience this is not an easy “skill” to learn.
Alot of this depends on the engine used, and its capabilities (pros/cons). And of course the project itself. Honestly theres only Unity or Unreal, you have to choose which engine is best suited for your project, and then deal with the pros and cons, and dig in and deal with it…simple.
I’d say the hardest part of any development project (not just games) is emergent complexity. It’s the constant struggle against complexity that decides whether or not the project will survive. Slack off and the project will gradually start dying until nothing can be done anymore. The only solution is to bite the bullet and refactor asap.
I’ve done ton of technical stuff, like custom GPU raycasters, soft body simulations, custom physics engines, but nothing can compare to the overarching complexity.
I also find emergent complexity to be the most difficult thing. It’s easy to tackle one small task but achieving that ‘more than the sum of its parts’ aspect can be challenging.
Also, it seems like every project has data that apparently has its finger in every pie even though it doesn’t seem like it should, and you can’t really think of a way to constrain and manage it properly. It feels like a weak point in the project where bugs could start appearing.
That said, most things in game dev like any project can be done by some basic overall planning and then focusing on a small scope at a time.
That’s a good one, you can address it simply having more ‘wasteful’ classes (it’s not waste, it’s just people get so wrapped up in architectures they forget Unity has a perfectly good component based one). The good thing about having a ton of components is that it’s very, very optimisable later because you’re keeping scope really small in individual blocks. So waste now, want not later (or something).
Divide and conquer and all that. The connectivity can be left to the classic references model. Honestly it seems bad but it’s the best way to finish a game in Unity and the easiest structure to optimise later.
Agree 100%. In my opinion, unless you have performance issues, a game should be built like a state machine, components should be built to closely resemble real objects or specific behaviors, and events should be used as much as possible to modularize things and reduce scope.
When you know exactly what’s what, then you can go in and abstract away whatever needs to be abstracted away, which probably isn’t much.
This stuff won’t usually be a bottleneck anyway, the method people are using to solve a problem is 99% of the time, the problem, and that can only be addressed with experience. So I guess most of the time, it’s just a lack of experience. I started coding in 1982 and along the way figured out that it’s best not to fight the platform.
For Unity it means using game objects, components and wiring those up. Don’t fight it unless reinventing the wheel for everything that touches it sounds like a great idea. Unity learned this the hard way themselves with DOTS as well (hehe).
And abstracting something in Unity is abstracting twice, since Unity abstracts everything. You’d want any abstraction you do to be kept to a bare minimum, for example if you had a complex (and I mean complex) inventory or rpg system.
That list is all technical stuff. Some of it is challenging, sure, but none of it is the hardest in my experience.
For me, the hardest part is deciding where to put my or my team’s limited time and resources to get the best results. You’re often dealing with multiple unknown factors in those decisions and, unlike the technical stuff, there’s no testing or QA you can do afterwards to check that you got it right.
Another hard thing is making “simple” changes late in development. “Hmm, it’d be great to tweak how this thing works. The code will take an hour and the art half a day… no sweat. But then we need to change the tutorial, modify three levels, update some writing, and get the voice actors back to re-record a bunch of lines. And, of course, test all of that once it’s done.” And it could easily be a lot more than that.
It’s the most over-engineered common example. It’s not particularly difficult, but it does tend to cause the most over-engineered abstraction or patterns.
