A windows service is generally just an ordinary program (albeit with service entry point functions), that is designed to run as a background process without an user interface of its own. Most server-type applications (such as an online game backend) are well suited for such use.

You don't want to mess with realtime priority (or in general, deviate from the normal priority) in most types of applications. Real-time will choke all other processes - including I/O services - if you run any tight loops in it and this may actually be harmful to the performance of your application. You can't overcome virtual hosting priority with that, though, as the physical resource access is timeshared at a lower level.

The realtime priority class is useful in scenarios where you have, for example, an analog sensor from which you need to extract continuous data and you want to miss as few samples as possible. The priority class does not actually guarantee realtime performance though, because other processes (such as kernel sound mixer) also use the same priority class and will compete against your process. In addition, the OS really needs to do some stuff in the backround to keep your app and others running :)

One thing to mention: do not, under any circumstances, run your service as a system user. Create a special user account with its own limited rights just for running your service. Anything else is a security liability.

You can specify the account used to run a service by setting the service properties at installation time or after installation. If you go to the service manager (run services.msc), right-click on any of the services, and go to the "login" tab, you can view (and change) the account used to run a given service. Do not go changing the logins for other services than your own, if you want to spare yourself from agony.

As ApochPiQ said, it is very dangerous to run your own services with the system account. Since it can access anything on the system, any security-related bug in your software could cause a total system compromise (AKA "ownage"). A best practice is to set up a service account and give it limited rights to do just what it needs to do.

Some services, such as drivers' application interfaces, do require system access in order to be able to talk to low-level components.

UDP is a part of the internet protocol stack; you don't have to explicitly declare dependency on it, unless you write a kernel level service that could potentially be loaded before the network stack. You don't want to go to kernel level for a game server :)