Nowadays, one thing that deters me from putting lots of effort into one game is how long that game will be playable. The first few generations of gaming can be easily emulated(like how they are on wii virtual console), and are still played today.
I'm focused more on directx and java. If i made a game using either of these 2 systems(which I find most appealing), would that game stay playable on newer computers? I know directx and java are supposed to run older versions, but I've seen a lot of topics and things on the internet where people have needed to downgrade to play old games, or where newer versions run older versions with less quality, causing glitches. I know enough about c++ and how games work, so I'm sure I could learn whatever's needed.
So say if I made a game today using c++ or some other powerful gaming language, would that game be reasonably easy to play on future computers?
0
A games lifespan
Started by zeybey1, Aug 10 2012 09:59 PM
9 replies to this topic
Sponsor:
#2 Members - Reputation: 107
Posted 11 August 2012 - 07:59 AM
You spoke to a interesting point about old games. Why the old games work less quality on newer computers? I think, maybe the reason is developers's a premeditation or mismatchs between old versions and new versions. I don't know which one but me too wonder.
#3 Members - Reputation: 283
Posted 11 August 2012 - 01:20 PM
The only way of being 100% sure your game can run on future alien hardware, is to write your own virtual machine and compile your game so it runs in that virtual machine. Then you have to make sure your virtual machine runs identically on all platforms in the future.
Or just try not to rely on bugs in OpenGL, DX and/or JVM and update your game when there are breaking future changes.
I'd like to replay Sub Culture from 1997 (http://en.wikipedia.org/wiki/Sub_Culture), I haven't been successful at it so far. It is frustrating...
However, the language used doesn't count as much as the libraries you're using. I believe Sub Culture was written in C or C++, but it's using an ancient version of Direct3D / 3Dfx for rendering. The game _starts_ on modern hardware and operating systems, but doesn't run very well (or at least I haven't been able to).
Or just try not to rely on bugs in OpenGL, DX and/or JVM and update your game when there are breaking future changes.
I'd like to replay Sub Culture from 1997 (http://en.wikipedia.org/wiki/Sub_Culture), I haven't been successful at it so far. It is frustrating...
However, the language used doesn't count as much as the libraries you're using. I believe Sub Culture was written in C or C++, but it's using an ancient version of Direct3D / 3Dfx for rendering. The game _starts_ on modern hardware and operating systems, but doesn't run very well (or at least I haven't been able to).
Our game we're currently working on: http://games.studiofreya.com/
#4 Members - Reputation: 629
Posted 11 August 2012 - 04:09 PM
It depends on how far into the future you're talking about. If you made a game today using the latest technology, it would most likely still work fine through the next 2 or 3 major revisions of Windows if you're targeting Windows PCs.
You're not going to write a PC game that is guaranteed to work out of the box 20 years from now on the modern systems of that time. It's just not going to happen, no matter what technology you use.
On the other hand, 20 years from now today's technology may very well be able to be emulated on the technology of that time, just like the original Nintendo system can be emulated on modern systems.
If you stick as close to the standards as you can and try to write platform-agnostic code where possible and isolate any platform dependent code, it should be relatively easy to update it to take advantage of future technology if you are still in the picture and interested in the continuing life span of your game.
You're not going to write a PC game that is guaranteed to work out of the box 20 years from now on the modern systems of that time. It's just not going to happen, no matter what technology you use.
On the other hand, 20 years from now today's technology may very well be able to be emulated on the technology of that time, just like the original Nintendo system can be emulated on modern systems.
If you stick as close to the standards as you can and try to write platform-agnostic code where possible and isolate any platform dependent code, it should be relatively easy to update it to take advantage of future technology if you are still in the picture and interested in the continuing life span of your game.
#5 Members - Reputation: 1027
Posted 11 August 2012 - 04:15 PM
And of course you can always make the game open source, so if people wabt to keep playing it they can make it work.
The lack of awesome free resource gathering building sandbox games capable of running an user made 8 bit computer in the world disturbs me.
#6 Members - Reputation: 1006
Posted 11 August 2012 - 04:20 PM
Yeah, APIs can be tricky beasts. Things become deprecated or obsolete, bugs are fixed, occasionally new bugs are introduced. And then sometimes your OS or even your hardware gets whipped away. Ironically some older games suffered badly from the CPUs getting faster because they had no speed limiting code in them, but I believe and hope that's no longer an issue because developers have wised up. Realistically a game can survive almost anything if it's fans want it to, or if the developer is willing to keep it updated.
#8 Members - Reputation: 3503
Posted 14 August 2012 - 05:49 AM
I find that to be the opposite myself. Lots of games tend to hard code things instead of using the proper method of obtaining them. Or they relied on old behavior that is no longer existent.Games that were written to Win32 a long time ago still work for the most part. I haven't tried running something that with written to DirectX 5 (say) but I imagine there'd be problems...
Lots of old installers use hardcoded paths that don't exist anymore, and predate the new user / permissions login / file system. So even getting some of them installed is a huge pain in the ass.
Then there are issues like OpenGL's never ending evolution. Quake 2 can run horribly on newer setups because all the extensions have been removed or renamed, so the engine uses slow fallbacks for everything. It ran beautifully at insane resolutions on my 1999 box with a TNT2. It chugged on my 2007 box!
#9 Crossbones+ - Reputation: 1335
Posted 14 August 2012 - 11:10 AM
I find that to be the opposite myself. Lots of games tend to hard code things instead of using the proper method of obtaining them. Or they relied on old behavior that is no longer existent.
Games that were written to Win32 a long time ago still work for the most part. I haven't tried running something that with written to DirectX 5 (say) but I imagine there'd be problems...
Lots of old installers use hardcoded paths that don't exist anymore, and predate the new user / permissions login / file system. So even getting some of them installed is a huge pain in the ass.
Then there are issues like OpenGL's never ending evolution. Quake 2 can run horribly on newer setups because all the extensions have been removed or renamed, so the engine uses slow fallbacks for everything. It ran beautifully at insane resolutions on my 1999 box with a TNT2. It chugged on my 2007 box!
I guess it depends on the game.
I was talking about small things which we'd call independent games now and used to call shareware then, mostly because these are the sorts of games that I find on old CD's when rummaging through boxes collecting dust in my apartment. A lot of these sorts of programs had minimal installers or no installers, so that fact jives with what you say above ...
I did find a CD recently for an Activision game that was a "modern" remake of Pitfall from '95 (at least that's what I'm gathering from consulting wikipedia), I'm not sure what DirectX it was expecting, can't remember what shipped with Windows 95 -- was it DirectX 5?. Anyway, that thing crashed at startup which was a shame because I remember it being pretty good..
