Advertisement

Porting: expectations vs reality

Started by June 23, 2024 07:02 AM
1 comment, last by Tom Sloper 5 months, 3 weeks ago

Hi!

So, I need to ask you some questions, because I couldn't answer it to myself.

In short:

  • in gamedev about 6-7 years
  • mostly gameplay programming, in Unity
  • in transition to Unreal Engine
  • joined co-dev/porting company, where after 1 project in Unity, I was assigned to porting team (at that moment, they need a programmers, so I joined them)

In short, I did 2 ports:

  • first one was to be fair optimizing DLC content and mechanics for PS4/XBox One, so I used devkits, tools, but didn't touch consoles API
  • Second one was sadly canceled, but it was in Unreal Engine. Mostly, I worked for UI gamepad support, and implementing some cert requirements (game was multi, so there were more requirements)

Now, I'm working on Switch port of some game that was released a few years back, also on Unreal Engine.

The prject is short, in about 5 months we have to deliver final build. Probably we will done it, we've got a experienced team.

However, I imagined porting different:

  • using console APIs
  • learning hardware, how it works, its features
  • making the ported version as best not only in optimization, but also in gameplay by utilising some platform features

In my reality, it looks like:

  • practically no programming - project is mostly in messy Blueprints. We've got no documentation, so everyone didn't have enough knowledge about the codebase
  • UE does a lot in terms of porting, so instead of coding features, you are configuring and fixing Epic/Platform bugs
  • Lots of bugs from nowhere like GPU hangs, some gameplay issues, even if you don't touch gameplay code at all
  • I'm not feeling like a gamedev, rather as IT who try to move some levers in codebase/engine configuration, to just make it work
  • Console API - it is, but it's mostly done by UE developers, mostly in my case is reading docs and source code
  • Iteration time are not the best - while we could speed it up, by not package project everytime etc. it's not so snappy as from gameplay/UI part
  • Project is moslty optimization, but on the code side it's not that much, as the best gains we've got from optimizing art content (done by Technical Artist), or mangling with engine configuration (magic levers for me, done by our senior)
  • I don't have knowledge about how UE works internally (altough I'm trying my best), how platforms works, how rendering works both in UE and in just general, just mostly - I don't know
  • There is a lot of discussions - with the client, internal with the team, probably it will be some discussions with platform vendor…
  • Because we don't know enough codebase, it feels like we've got black box and I'm afraid to do changes, to not break gameplay or something, to not lost precious time

To be honest, I'm interested in engine/platform side of gamedev, but it's not the same as above. And what I think, every next porting project could look the same.

And at this moment, I don't know what to do:

  • optimizations seems to be very hard, and often a lot of time you didn't see expected results
  • I asked to move to the gameplay things on the other team, but that would depend on company projects and capacity
  • I just don't feel like a game programmer, rather as someone that presses some buttons, write a few lines code, on the unknown codebase, on the unknown game that I don't have any influence on it

And I just want to ask - is it normal in being porting programmer? Or just I've struggle internal with fear of no knowledge, or something else…

xqwzts251 said:
expectations vs reality

is it normal

Your expectation that the process would be better is normal. There may be things you can do to improve the situation. Most likely, the best course of action is to step up your communications with other programmers on the team, and your manager as well. Bosses know the saying “don't bring me problems, bring me solutions.” Without speaking negatively about the current process, explore ideas that may help improve the process and communications. Be specific about where the pain points are, and think about what can be done to make the process go more smoothly.

-- Tom Sloper -- sloperama.com

This topic is closed to new replies.

Advertisement