I’ve been going through a course on udemy and learning unreal engine first time ever consistently for the past month, but haven’t finished a game just yet, and I don’t think I care enough to put any effort on anything other than gamedev. It has been my passion since like 6 years, that’s why I left my old job as an Ops engineer; should I continue and work on different projects simultaneously (opengl and unreal) or just stick to one. FYI, I’m not employed atm and would hope to work on gamedev professionally. I appreciate any advice to build my portfolio or any keypoints to get better at gamedev.
tl;dr would learning unreal and opengl simultaneously benefit me to get hired in a gamdev studio or should i stick to unreal and finish some games first?
Please note that gamedev is much much more than the graphics framework. I’d suggest that you keep on learning to make small games in Unreal. It’s important that you finish your small games, they should be polished, not half-assed.
I myself am writing a game with OpenGL, but I have prior knowledge and experience in C++, Opengl, game modding and simulation. It sounds like you are starting out in everything. So better keep yourself focused on one thing.
I’d use to say “at least OpenGL is cross-platform” but both Microsoft and Apple prefer their alternatives (DirectX and Metal). :(
OpenGL has much more permissive licenses so you can sell a finished game without licencing fees. From a technical standpoint, OpenGL is much more general, while unreal makes a lot more assumptions about your game.
Unreal tries to be a “Instant game, just add content” including almost everything you need, but that makes things very annoying whenever you violate one of its assumptions about the game. OpenGL is just a graphics library, its job is to quickly draw 3d polygons to a 2d screen, allowing fast shading. (texturing, lighting, etc) With OpenGL, it is your job to provide the polygons, to animate them, to nicely light them etc.
If you are making a standard FPS or side scroller, unreal will be easier, but as soon as you start doing weird stuff, like massive procedurally generated worlds, fully destructible environments, portals, lighting at massive scales (millions of light sources, like in Terraria or Minecraft) OpenGL is often easier.
TLDR: OpenGL does less handholding then Unreal, but you do weird stuff, you will not have to fight it unlike Unreal
OpenGL is good for learning 3D graphics, but isn’t used in games any more. It’d be better to know DirectX 12 and Vulkan, but those are hard to impossible to learn without experience with some other API first IMO.
Just learning Unreal Engine will keep you from getting hired for a lot of jobs that don’t involve that engine (for example, all Unity projects). Being a general graphics programmer opens a lot of doors.
I think it depends what kind of games you are wanting to make. If you want to work for triple A making the next God of War then yeah they aren’t using OpenGL. However, if you are interested in smaller indie games then OpenGL is still going to be used. I’m using OpenGL since my game is pixel art and would so the performance gain from Vulkan would mean nothing.
The problem isn’t performance, the problem is that OpenGL was designed for another era. It’s a global, single-threaded state machine. Getting it to work together with a rendering engine is very hard, because you have to keep track of all of the state to avoid interference between different parts of the engine (so the output would be broken if certain parts are executed in the wrong order).
This can probably be somewhat alleviated by using the Direct State Access feature since OpenGL 4.5, though. I haven’t used that one yet, because it’s not available for WebGL (and that’s the only place where I’m still using OpenGL). Note that this isn’t available on Apple platforms, because Apple stopped updating their OpenGL implementation at version 3.3.
I agree that Vulkan isn’t really a good choice for indie devs. However, WebGPU is a pretty good API that removes most of the complexity of Vulkan (like the manual thread synchronization and memory management) while keeping all of its concepts. It’s also available on desktop, for example via wgpu.
