33
\$\begingroup\$

I am preparing for an internship as game programmer at a world-renowned game development company. When I searched their website for necessary prerequisites, it showed me this:

Added Advantage

  • Knowledge of DirectX/OpenGL.
  • Strong command on 3D Maths and Physics.
  • Visual Studio IDE for C++ development.
  • System Programming and OS concepts.

What exactly do they mean by system programming and OS concepts?

Should I be studying Windows programming? Or should I be going with Linux programming (meaning they want me to know the important concepts). Or is it something totally different?

\$\endgroup\$
5
  • \$\begingroup\$ Comments are not for extended discussion; this conversation has been moved to chat. \$\endgroup\$
    – user1430
    Commented Aug 24, 2017 at 16:45
  • \$\begingroup\$ "Should I be studying Windows programming? Or should I be going with Linux programming" Both where possible. At least have a read of their APIs, maybe try to do a simple 'open a window' with the respective OS APIs so you learn how different they are and what an effort it can be. \$\endgroup\$
    – Pharap
    Commented Aug 25, 2017 at 19:03
  • \$\begingroup\$ @Pharap Technically, there is no Linux "OS API" that can open a window, and it's better to use glut, glfw, or similar to open a window so it will work with both X and Wayland (and Windows and macOS). \$\endgroup\$
    – Majora320
    Commented Aug 25, 2017 at 21:33
  • \$\begingroup\$ @Majora320 No, but there is a shell API that handles it, and they tend to be specific to Linux distros (i.e. X is used on some Linux distros, but typically not on Windows and Mac). You could also use glut/glfw/SDL/whatever, the important point is to take a low level approach so that the OP can use the implementations to learn about the underlying concepts (event messages, user-land vs os-land etc). The portable/higher-level APIs tend to abstract away a lot of stuff that might hinder the learning process. \$\endgroup\$
    – Pharap
    Commented Aug 25, 2017 at 21:42
  • \$\begingroup\$ @Dhannanjai If I may be so bold, I would like to recommend a book called Operating Systems DeMYSTiFieD. It helped me a lot in my college years during the hardware unit. It explains many of the important concepts of operating systems like POST, thread scheduling techniques (round-robin, ordered queues etc) and drivers. \$\endgroup\$
    – Pharap
    Commented Aug 25, 2017 at 21:46

5 Answers 5

Reset to default
53
\$\begingroup\$

"System programming" (or "systems programming") tends to mean programming done at a lower level of abstraction than (for example) gameplay programming. Gameplay programming is usually about building the actual game mechanics and front-facing features that a user might see, whereas systems programming is more about building the frameworks upon which gameplay programmers work.

This might mean graphics, resource loading and streaming, audio, memory management, file IO, platform abstraction APIs, et cetera. The details vary quite a bit, and because there are no standards for job titles in the games industry there are similarly no standards for the names of programming domains. At one studio, you may find that "systems programming" means everything I listed above. At another, you may find that they distinguish "graphics programming" as a separate domain and call every other non-gameplay-programming task "systems programming." In yet another, they might not use the term at all and just call it "engine programming."

Since it's a lower-level domain, and typically involves interfacing more directly with the platform-specific APIs for whatever platforms the game is being built for, having knowledge of those platforms will be helpful, as will having knowledge of the more general domain (e.g., of OS concepts without regard to how specific OS's work, such as what virtual memory is, or how threads work, how IO buffering works, et cetera).

\$\endgroup\$
1
  • 2
    \$\begingroup\$ In a nutshell, I'd say non-systems programming (the actual game) will be mostly platform independent (don't really care if it's Mac/PC/Xbox), whereas systems programming will be much more platform-specific (in order to provide the platform-independent layer for the non-systems programmers). \$\endgroup\$
    – TripeHound
    Commented Aug 25, 2017 at 8:12
21
\$\begingroup\$

Josh's answer is really good but I figured I'd throw down some bullet points about the Systems team where I work. I don't work on Systems but I work with them a lot. The responsibilities of a Systems team varies a lot from company to company.

Our Systems team is in charge of a lot of stuff:

  • Math Library
  • STD Replacement Library
  • Core Game Framework
  • Core Application Framework
  • Input
  • Event messaging
  • Component-Entity systems
  • Script binding
  • (and more)

There's a lot of Windows and Linux domain knowledge here as well as a lot of knowledge of Physics, core game logic and low level memory management. Systems teams will usually be involved at least in some part in each supported OS since most of their projects sit on each OS at a pretty low level.

Some things that might fall under a "Systems" team that we break up into separate teams (but our Systems team still interacts with pretty heavily):

  • Physics
  • Linux (dedicated server)
  • Direct support for other OSes (iOS/Mac/Consoles/etc)
  • Build Systems
  • Audio
\$\endgroup\$
0
\$\begingroup\$

Systems programming is very well defined, but companies try to stretch it to their needs. If you are using or writing system calls, you are doing systems programming. System calls are the functions that are provided by the kernel, or userspace drivers. This includes OpenGL as it is basically a driver.

\$\endgroup\$
2
  • \$\begingroup\$ I don't think graphics programmers (OpenGL experts) would apply to a System programmer job... \$\endgroup\$
    – Vaillancourt ♦
    Commented Aug 25, 2017 at 19:50
  • \$\begingroup\$ Graphics programming and OpenGL programming are two different things. One deals with computer graphics algorithms, the other deals with the particulars of the API. \$\endgroup\$
    – Cem Kalyoncu
    Commented Aug 27, 2017 at 6:35
0
\$\begingroup\$

Added advantages listed above are mostly for game engine programming when necessary, thus involves utilizing low level APIs. Systems programming here expects you to know how to make calls to OS audio, process management, file manipulation, network calls and so on...

\$\endgroup\$
-5
\$\begingroup\$

Since they reference Visual Studio, system programming refers to writing programs specifically for the windows Operating Systems, meaning: windows syscalls (for example there is no fork-exec chain), user accounts, where to put your user specific data, data sharing models in windows Look up,for example how you can check the current user in visual c++ Or how to start a new process

OS concepts, refer to scheduling, file abstraction, threads, userspace etc. os dev wiki and forums can be a good read

User authentication is for example in both sections, since windows is a single user operating system, that has a much deeper kernel integration of user management and user interface.

The msdn is the knowledge base for all things windows programming apis, libraries etc https://msdn.microsoft.com/

Stackoverflow for the actual coding if you are stuck.

\$\endgroup\$
6
  • \$\begingroup\$ Windows is not a single user OS. \$\endgroup\$
    – Maximus Minimus
    Commented Aug 25, 2017 at 5:18
  • \$\begingroup\$ And system programming does not mean writing programs specifically for a given OS. Drivers for example can be easily cross-platform. Since actual Windows syscalls differ from release to release so it's usually handled through kernel32.dll and user32.dll instead of talking to kernel directly. \$\endgroup\$
    – Maja Piechotka
    Commented Aug 25, 2017 at 7:58
  • \$\begingroup\$ @MaciejPiechotka Systemsprogramming is programming on a level near the hardware // operating system. The part of a driver that is cross platform is the api, not the syscall wrapper. In Linux, the syscalls are wrapped as well in libraries, otherwise you couldnt change the implementation beneath.For example getting the cpu temp via registers are very diffrent between oses. \$\endgroup\$
    – Git
    Commented Aug 28, 2017 at 12:43
  • \$\begingroup\$ @LeComteduMerde-fou if you only look at how the users are handled, it is. -> Security Keys (ctrl+alt+delete), the GUI, etc. Unix // BSD handles the users completely diffrent \$\endgroup\$
    – Git
    Commented Aug 28, 2017 at 12:44
  • \$\begingroup\$ @gismo I write drivers for living - there is much more to driver which is not OS-specific part then API ;) My point about syscalls was separate then the about drivers. Of course in Linux you have libraries but my point is that Linux have an ABI for syscalls - i.e. syscalls, at least in theory, are stable and documented (and closly modelled after POSIX). For Windows the userspace<->kernel interface is not considered to be stable across releases. \$\endgroup\$
    – Maja Piechotka
    Commented Aug 28, 2017 at 13:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .