Will Longhorn change the gaming industry?
Longhorn SDK and info. can be found here; http://longhorn.msdn.microsoft.com/
and here; http://www.winsupersite.com/
I''m not too familiar with Longhorn, which is why I''m bringing up this topic. With the creation of WinFX and DirectX for .NET, it seems that .NET developers will have a significant advantage of C++ developers; productivity. If the WinFX and DirectX.NET SDK are only a marginal speed decrease from C++, I see no reason why C++ developers shouldn''t start using .NET when Longhorn is released.
I have heard on these forums that .NET apps will actually run faster on Longhorn compared to native apps, however I have not seen any such evidence. It does make some sense though, since native apps will somehow need to talk to the new, managed WinFX. This can only mean translation, which results in a slower app.
Games are now being made by large corporations, and .NET can be the answer to small groups of developers that work out of their garage, giving them a chance to enter the gaming industry, much like the old veterans did back in the day. Heck, even the larger gaming corporations may look at .NET in a new light. After all, shorter development times equals more money for them.
There is one thing that I am worried about however, and that is the overall speed of Longhorn. I heard that you need quite a bit of ram, and a minimum of a 1ghz processor just to run it. That doesn''t sound too good. If forced to, will developers just start developing exclusively for consoles and linux?
Anyone else have some thoughts on this?
A 1 Ghz machine is below entry level anymore. Why should this be a breaker?
In any case, Longhorn will take a few years to hit market saturation. By then 8-10 Ghz machines should be common if Moore''s law continues to hold.
In any case, Longhorn will take a few years to hit market saturation. By then 8-10 Ghz machines should be common if Moore''s law continues to hold.
Well, there are already more sales for videogames than PC games, and I expect that to increase with the next generation of videogame systems, considering developers will want the added control of an unmanaged environment, plus a quickly growing userbase. More games devloped does not nesessarily mean more money, because if a market gets saturated, prices fall.
But don't get your hopes up on Linux, I don't see any good reason for developers to target that platform.
[edited by - PlayGGY on December 14, 2003 10:04:52 PM]
But don't get your hopes up on Linux, I don't see any good reason for developers to target that platform.
[edited by - PlayGGY on December 14, 2003 10:04:52 PM]
Will developers also have to convert their code for portability between window versions? Surely the same code will not run as effectively or as fast on at least one or the other, i.e. managed code on current windows or un-managed on longhorn. Also will the successor to the X-Box use the same api as longhorn?
Food for thought really.
Food for thought really.
To me, .Net is only useful for creating a window as far as game development is concerned. Why would i ever use the Window Form features(which simplifies Win32 alot) in a game? We still will need to make 3D API calls to do our rendering, so in what way will .NET make us more productive?
Game development is not held back by programming skills or productivity. You can still make a kickass renderer or game engine within a year, especially now that hardware is faster and directx offers more and more functionality. To make Quake 1 (a pure software renderer) requires lots of skill and work, math insight on university level, and genius. A game engine now is easier.
The bottleneck is content. A game is maybe 5 MB of executable code and 2 GB of graphics, sound and levels. A game usually has 2-5 programmers and 10-25 artists working on it.
The content problem will prevent garage or one-man development of professional titles.
The bottleneck is content. A game is maybe 5 MB of executable code and 2 GB of graphics, sound and levels. A game usually has 2-5 programmers and 10-25 artists working on it.
The content problem will prevent garage or one-man development of professional titles.
quote:Original post by Fidelio66
Game development is not held back by programming skills or productivity. You can still make a kickass renderer or game engine within a year, especially now that hardware is faster and directx offers more and more functionality. To make Quake 1 (a pure software renderer) requires lots of skill and work, math insight on university level, and genius. A game engine now is easier.
The bottleneck is content. A game is maybe 5 MB of executable code and 2 GB of graphics, sound and levels. A game usually has 2-5 programmers and 10-25 artists working on it.
The content problem will prevent garage or one-man development of professional titles.
I agree with this 100%
I mean using C# and MDX sure your productivity goes up usually at least 40-50% and you can get things done faster.
But who really cares how fast the code is written if you just don't have the art/sound =]
[edited by - Imperil on December 15, 2003 12:28:04 PM]
Well my first thought is how the heck can you say that its only useful for creating Win Forms? When the SDK''s for DirectX 9 are managed also. The API calls are still managed. Its not like you are forced to use "unsafe pointers". Although you can ...
But the thought of being able to get a game developed faster means that with a few books and good programming skills. 1 or 2 programs can put together something they couldn''t have in C/C++ using pointers. As that seems to be the biggest drag on everything. Not to say they are bad. Just not fully understood with a lot of the developers that are on these boards.
Yes it is true they continue to say C/C++ apps unmanaged are going to be slower via Win32 API now going to be fully managed. Which means any app making a call will be forced to marshall the data between the 2 ...
I am not worried about the specs of longhorn hardware requirements. As already noted in a previous post. Just worried about all my current apps that will break or function poorly because of the way that the API''s are exposed to native machine imaged code.
However you can say that it will be more productive to move to it. And I think the move for small groups like many on these boards will have a great advanage they never had before. Being able to prototype something in C#, then post the thing as a center peice of how your team works together or market yourselves. In the mean time, for larger groups C/C++ is mostlikely the better of all languages for games that will hit different types of PC''s, (ie ME,2K,Xp,2003)...
But the thought of being able to get a game developed faster means that with a few books and good programming skills. 1 or 2 programs can put together something they couldn''t have in C/C++ using pointers. As that seems to be the biggest drag on everything. Not to say they are bad. Just not fully understood with a lot of the developers that are on these boards.
Yes it is true they continue to say C/C++ apps unmanaged are going to be slower via Win32 API now going to be fully managed. Which means any app making a call will be forced to marshall the data between the 2 ...
I am not worried about the specs of longhorn hardware requirements. As already noted in a previous post. Just worried about all my current apps that will break or function poorly because of the way that the API''s are exposed to native machine imaged code.
However you can say that it will be more productive to move to it. And I think the move for small groups like many on these boards will have a great advanage they never had before. Being able to prototype something in C#, then post the thing as a center peice of how your team works together or market yourselves. In the mean time, for larger groups C/C++ is mostlikely the better of all languages for games that will hit different types of PC''s, (ie ME,2K,Xp,2003)...
afterburn: It sounds like you think that an amateur programmer can make professional programs with .Net, and I''d just like to point out that it is not so. Yes, they might be able to do whatever they can do faster, but I find that the main thing holding back amateur programmers is not getting the code out but knowing the algorithms. Being able to write something in 10 minutes instead of 3 hours doesn''t free you from knowing what you''re doing, it just lets you do it faster.
I also agree with Fidelio66 - the main problem for amateur game developers is not really the programming, because just about everybody can make something from all the tutorials online. The problem is the art. Think about it - calling something ''programmer art'' is not a compliment. Also, think about the help wanted forum - so many people asking for help, but so few groups actually getting together from there.
I also agree with Fidelio66 - the main problem for amateur game developers is not really the programming, because just about everybody can make something from all the tutorials online. The problem is the art. Think about it - calling something ''programmer art'' is not a compliment. Also, think about the help wanted forum - so many people asking for help, but so few groups actually getting together from there.
quote:
The bottleneck is content. A game is maybe 5 MB of executable code and 2 GB of graphics, sound and levels. A game usually has 2-5 programmers and 10-25 artists working on it.
The content problem will prevent garage or one-man development of professional titles.
I''ve heard of games being developed with ~10 programmers and ~4 artists. I think how many programmers and artists that are on a team depends entirely on the company, as all companies vary from one another. But one thing remains the same, all aspects of a game is built in harmony. If programmers save time by being more productive, then that''ll leave time for them to add more features to the game as they wait for the sound and art to be finished. Too many times have I heard "sorry, we simply do not have the time or resources to add that feature."
Games are not simply programmed in a year, leaving the rest of the development time for sound and music. A lot of games that "wow" us have been known to take several years of development (Half-Life 2 anyone?). From my understanding, they started on the Half-Life 2 engine almost immediately after the original Half-Life was released.
I''m not saying that a small garage team of 2 programmers and 1 graphical artist can whip up a game that is professionaly appealing in the visual terms, but in terms of technology it could very well be possible if they are given a more productive environment. Now, instead of a game engine taking 4 years to program in a group of two, it could very well be done in 2 years. This, unlike 4 years, sounds like a realistic goal. Imagine the time saved for debugging alone, that''d knock months off of your QA time.
On the flip side, I honestly cannot see how large corporations can ignore .NET when Longhorn is released. Games cost millions to make, surely a corporation is going to jump at every chance to save some money.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement