Game Design, Programming and running a one-man games business…

What a directx developer does in a steambox world

cliffski

Elaborating on my last post. Valve have made it pretty clear they are heavily betting on Linux. Microsoft, you missed the ball. You didn’t get the hint. What action did you take to get valve back? Apparently not enough. Regardless… Linux will be big for gaming. It’s 2% of my sales right now. This is going to grow and grow fast.
This is no big deal to me, apart from the fact that Linux also means OpenGL. I currently have my own engine which uses DirectX. What should I do? Here are my options…

steambox1) Do nothing.
Just stick with it. 2%? Even if it goes up to 20% so what? My current system is me doing the directx version, then paying a contractor to handle the OSX & Linux ports by converting it all to OpenGL. This works fine so far. This option is easy, but it seems like I just go further down a dead end. I don’t want to be the last guy using DirectX.

2) Prepare my engine to be more cross-platform friendly
I could re-engineer my code so that it’s more modular and easier (re: cheaper, faster) to port to OSX/Linux. This way I still keep directx, but make things simpler for a future transition. This is appealing because it’s a hedge towards either direction, and frankly engines should be built like this anyway.

3) Learn OpenGL.
This is the hardest because it involves serious work. I know everyone will say ‘it’s really similar’, but being ‘familiar’ with OpenGL isn’t what I want. Being VERY sure I know the BEST way to use OpenGL for my purposes is what I need. I love optimizing. I love pushing to get as rich a 2D experience as the hardware allows. I don’t want to trade a really fast DirectX engine for a slow OpenGL one. This involves the most work, to do it right. There is huge opportunity cost for that time as a programmer. This is also by far the most future-proof.

4) Hire a full time Linux/OpenGL coder.
Not a sensible option for me. I couldn’t keep them busy, I still don’t learn anything, and this is effectively 1) but more expensive and with more admin. All it does is guarantee me availability, but at too high a price.

5) Switch to middleware.
An option for 95% of devs. I hate middleware in general, but I also do something very unusual. The engine for GSB 2 works in a very specific way. At it’s core, it is a heavily optimised, shader & post-processing based, lots of render-target flipping 2d engine that assumes a huge amount of 2D objects. I’m not aware of any engines designed specifically to do this except mine. Plus there are costs in terms of learning that new engine,  which represents investment in something I neither own or control. I don’t like this.

I’m thinking about this a lot. I’m currently favoring 2), Possibly 3). I have discounted 4) and 5). Doing 1) seems lazy. This is something I need to get right at some point this year.
Feel free to add your thoughts :D

15 thoughts on What a directx developer does in a steambox world

  1. Hey Cliff,

    I jumped from DX to OpenGL when coming back to games. It was a good decision. I now build natively on OSX and have a buildchain set up for Windows using MinGW. I’m also building my own engine (mostly because I want to, which isn’t a good commercial reason, but it makes sense for me.)

    Post-Elixir I ran my own consultancy business, which meant I did a lot of (4) and am now avoiding hiring people at all costs: it totally changes the business. (2) sounds like a good short term option, moving to (3) over time.

    Chris

  6. If at some point you decide to switch to OpenGL, you really can´t do that much wrong if you use Core Profile OpenGL. The only problem is that the learning resources are still quite limited and I learned the most on how to do things right from apple presentations, also there is this great one from nvidia/valve: https://developer.nvidia.com/sites/default/files/akamai/gamedev/docs/Porting%20Source%20to%20Linux.pdf
    The biggest problem I have with OpenGL are Vendor extensions which one usually wants to use in the long term for the best possible performance. And that can get kinda messy with all the different extensions out there only supported on some hardware. On the other hand it allows for some great features on some hardware…

  7. Separating all your game code from graphics code sounds like the way to go, that’s what all the multiplatform engines do and all a steambox boils down to is another platform target.

  8. I still don’t believe the hype. I’m a hard-core gamer –a PC gamer– and I don’t want a Steam Box. It offers nothing for me. Playing PC games on a console? Don’t the other consoles already offer me that? Poorly? (Before anyone flames me, I do have a 360, PS3, and Wii, and I use them to play games with my kids or watch TV. When I *Game*, I am on my PC.)

    That said, if you want to capitalize on whatever percentage of PC gamers finally get around to saying “yeah, I’d rather play this game on my TV rather than my PC”, I’d go with option #2. Since you are the type to want to write every line of code, consider writing your game engine with an abstraction layer that can be implemented just as efficiently in DirectX as it can OpenGL.

    1. I admit I’m not following the SteamOS & Steambox hype myself. Compared to a Windows system it’s not significantly if any cheaper and the OS is going to have to go a long way to overcome its many limitations. What, at this point, does it get me over just using Steam Big Picture?

      If i want a simple console experience everything I’ve seen suggests they still aren’t there and of course I expect before Steambox does become viable (if it ever does) that we’ll see the Xbone and/or PS4 approaching Steam levels of convenience, simplicity and pricing when it comes to digital purchasing.

      My experiences with Linux over the years are mixed but I do not see it as the holy grail, or a great improvement over Windows for all the use cases or users that its supporters suggest it to be. No comment on Gabe’s response to the direction Windows is going or anything else, I will just have to see these new steam thing succeeding to believe it.

      That said if you can learn and accomplish what you need in OpenGL anyway and have less future costs and efforts involved in supporting multiple platforms I see no reason to stay tied to DirectX.

  9. Have you considered using middleware like SDL 2.0 as a midway point version of #2 on your way to #3? It could be your “first” version of OpenGl and a Mac solution without having to ditch all the custom DirectX code. You can use OpenGl “through” SDL and slow gain acumen with OpenGL without having to make a full commitment to learning everything at once. Just an idea.

  10. There’s also winelib that lets you compile Windows programs under Linux, with (apparently) minor changes.

    Another option would be to open source the engine and hope that someone ports it for free. :-)

  11. I’d love to hear what convinced you that the future is Linux. While it’s great news and I’d love it to be true, “Linux is the future of X” has a long, unpromising history. What did Valve say to make you think “this is where gaming is headed”?

  12. Hi Cliff

    I’d say “3”, that is, switch to OpenGL. Because (in no particular order):
    – OpenGL is kinda multiplatform now. Yeah, I know, there are now/can be future Windows issues but there _is_ OpenGL on Windows, and there is no DirectX on Linux or Mac
    – What you are really good at right now is not “DirectX programming” but “GPU programming via DirectX”. So you aren’t really switching to something completely new right now, you are going to talk to same GPUs, just slightly different way.
    – Modern GPU programming and your code is much about shaders and such anyway, and so no big difference
    – Right now is IMHO good moment of getting started in “new” (programmable pipeline) OpenGL which gets rid of much legacy stuff (fixed function pipeline), so relatively less to learn
    – Just a matter of personal taste, I guess, but I’ve always found OpenGL to be more elegant and less affected by particular company policy.

  13. Definitely 2. Take steps to insulate your core engine from the renderer and put a thin layer of abstraction between you and any native DirectX stuff. It’s a small, useful step that cracks open a path to a renderer-agnostic game engine down the road.

  14. “The engine for GSB 2 works in a very specific way. At it’s core, it is a heavily optimised, shader & post-processing based, lots of render-target flipping 2d engine that assumes a huge amount of 2D objects. I’m not aware of any engines designed specifically to do this except mine.”

    Perhaps option (3b) is to learn OpenGL, create the engine you need within it, and then look at licensing it out.

    There have to be other studios in your position. And it might fit in a little with your ambitions as a publisher if you can also be providing a proven engine and support for certain 2D games…

    If that’s not practical, I’d recommend (1) for now – for long enough to get the next GSB out the door – and then you can reassess. It doesn’t mean you can’t pursue a different route later.

Comments are currently closed.