Slashdot Mirror
Is .NET Relevant to Game Developers?
andrew stuart asks: "We've heard an awful lot about how .NET is the future and how .NET signals the end for COM based Windows development, but how far does this go? Is it really the end of COM? Will ALL Windows programming be done with .NET? What about games development? Will games be developed with .NET? If games aren't developed with .NET and Microsoft is killing COM, then what future for games development on Windows? Will there be DirectX for .NET?"
Of course, that really only applies to people who want to use a Microsoft product for building games.
In reality I think dotnet is what everyone thinks, a competitor to Java. How many highgrade professional games are written in Java currently?
You got me thinking, so I'm going to take a flyer here.
Remember back in the **OLD** days when Atari, Commodore and Apple games weren't launched from the OS, they were loaded from a boot floppy because we really didn't have OS's back then? (Unless you purchased CP/M, of course.)
Well, Knoppix has demonstrated an absolutely ridiculous level of competence at autodetecting hardware, and since . Would the gaming industry consider the possibility of using Linux as a development platform in a trend back to using bootable disks for games?
Think about it: a bootable CD that has the Linux kernel, drivers, support libraries and your game code.
PRO:
[Fully customizable and optimized kernel]
+ [NO OS OVERHEAD or CPU/RAM competition]
-----------------
= [Mad crazy performance out the wazoo regardless of what other spyware crap the boneheaded user has been suckered into installing.]
PRO: OpenGL, Internet Integration, divers filesystem support for saving games to floppy, hard drive, memory card, cdrw, THE INTERNET.
PRO and CON: Potential for DRM and proprietary CDROM file systems to limit piracy and legal backups.
PRO: Their kernels would be open source, so we could see if they were spying on our hard drives or personal data. (This might be a big problem because you're giving their cd exclusive control of your PC to play a game.)
PRO: Reduced support costs - you'd be distributing an embedded system that only includes the drivers YOU specifically choose.
CON: Game developers may start developing drivers again. (**shudder**)
CON: No downloading or listening to MP3's in the background while playing Half-Life anymore, though they could certainly throw in those feature if they wanted to.
Woah... Am I on to something?
Anyone else have any ideas to add?
"Lawyers are for sucks."
- Doug McKenzie
As a game developer, I am/will use the heck out of C# and .NET to develop software - just not the runtime portions of my games.
.NET allows me to use or not use various parts of the run time (assuming that we architected the interfaces correctly!) in a way that can both maximize usefulness (it looks like it will in the game!), and unit test the game code in a better environment.
.NET are robust enough for these - the .NET IDE proves that.
.NET are better for windows app development - either you have done it, and understand why MFC and C++ blow chunks, or you are in for quite a pleasent suprise when you write that first tool.
Tool development takes up an increasing amount of my team's time. We have custom tools for art manipulation, sound manipulation, and data warehousing. Not to mention our tool for level creation, which we hope to release with the game. All of these tools need to be robust, have clean interfaces, and be developed and changed quickly, and grow with the run time modules.
Remember that C# and
I won't go into why C# and
-Donut