undefined | Better HN

0 pointskabdib13y ago0 comments

Sound. Networking. Decent async file I/O. Threading libraries. Dynamic loading of components. Anti-cheat techniques (or any other security stuff you might need). Device input. Choosing and supporting a platform (and the follow-on customer support issues). Diagnosis of customer problems (because they _will_ have them).

0 comments

3 comments · 1 top-level

eropple13y ago· 2 in thread

Sound: OpenAL abstracts this decently. If you're not using it or an equivalent, you're doing it wrong.

Networking: Most folks building a bespoke networking layer seem to go with ENET, which is cross-platform.

Async file I/O: yup.

Threading libraries: something wrong with Boost Thread? (Boost gets coroutines, too, in 1.53, which I'm pretty excited about.)

Honestly, the biggest problem I see in writing a cross-platform game is device input. Trying to build a joystick/gamepad-based game for Linux and OS X are pretty painful. Fortunately I've lucked onto GLFW as a windowing toolkit, which handles the HID Manager boilerplate and other badness for them.

zanny13y ago

You can also just use the sdl, which provides abstractions for network, sound, graphics, and input. If you hit snags, you could just commit back the fixes to sdl proper. I've used it a bit and I have had good experiences so far with successful cross platform builds.

It also supports Android, so in theory you could almost have one code base with only a UI and input revamp for Android target every PC os.

eropple13y ago

SDL is a thing, I guess, but I personally have little use for it. I mean, I've tried it, of course; I'm sure most people have. But, and maybe it's just me, but if I'm going to have to do the legwork of wrapping some C API into a decent, lifecycle-manageable object model, I'm probably going to use the lowest-level one I can so I can state with authority that I fully understand what everything in my stack is doing at all times. Like, OpenGL's C API is super gross, but only very slightly less so than dealing with SDL. And while, sure, "you can commit the fixes back to SDL," you first then have to go unwind their abstraction to actually understand what the hell it's doing--which for me, given the relatively small feature set I need, is almost as much work, if not more, than writing it yourself.

Also, SDL 1.x is LGPL (instant dealbreaker, I build with static libraries on a Mac to avoid dylib hell) and SDL 2.x isn't done. So there's that, too.

In the spirit of abstraction and not having to build the object model I'd get for free with Direct3D, I used SFML for a while; the general idea of it is promising, but the abstraction is janky, it's desktop-only, and I still have a bitter taste in my mouth from the way they handled showstopper bugs in SFML 1.x as far back as three years ago: "Completely reproducible crashes on all modern ATI cards? Just upgrade to our incompatible 2.x alpha!". (2.0 still isn't out, which makes it super groovy.)

I now use GLFW for windowing/input, ENET for networking, and PhysFS for I/O; I can pretty easily use each of them in a way that maps pretty well to my own preferences for an object model and a mental model. Probably not scalable (for a multi-person project or a 3D game I'd almost certainly use OGRE rather than doing it myself), but nice for my purposes.

The only part of my codebase that isn't pretty trivially platform-independent right now, without any special effort, is in "platform.cpp", which does the tremendously difficult work of finding me the user directory and the appdata directory. =) I sure haven't done anything special to make it build both in Xcode (my primary environment) or Visual Studio.

1 more reply

j / k navigate · click thread line to collapse