next »

[Melly]

Looking at some old games recently, the type that you often have to go through all sorts of annoying hoops and tricks just to get working, often with less than stellar quality, made me think of something I saw fit to ask Technical.

How can one make games that last? Technology changes practically daily. There's always a new bell or whistle around, hardware and software becoming obsolete with more speed than ever.

Is there a way to code a game that can outlast some of those changes? Outlasting OS's seems a bit much to ask, but what about graphics and sound hardware? Or maybe some amazing idea I haven't been able to think of.

Truth is, computer programs are one of the most expendable and fleeting type of human creative work. A movie can often be enjoyed by wide audiences several decades after its release. Books last centuries if well conserved. You get a game that's 10 years old and all of a sudden you can't even make it run.

[Parthon]

Avoiding OS-specific or card-specific code is a good start.

The best way is to use libraries that will possibly update as time goes by, stick with plain compilers and don't add in complex assembler code.

Most of the old games don't work because they used specific or arcane DOS or Windows hooks that don't work any more. At the time it seemed like the best way to do it, but of course they weren't thinking about long term playability back then. Even more so, it's very hard to conceive what computers will be like in 10 years. Hell, 10 years ago we were running windows 98 on pentiums with directx 3.

Lastly: OpenGL, DirectX and the dozens of sound libraries out there were made specifically for this reason. As DOS games got broken under Windows 95, and card manufacturers were doing conflicting designs, the big industry people at the time invented a way to create an API and library independent of the hardware that would upgrade over time. Many of the games written with these libraries still work today, while those that don't, don't.

[jotapeh]

It's an excellent question, though I must say opening up my NES and cleaning the contacts off after 20+ years of neglect made me realize just how well built those little buggers were. Worked perfectly.

[increpare]

I know people involved with preserving/trying to run software from twenty/thirty years ago - stuff on magnetic tapes for archaic hardware/operating systems.  It's all a rather difficult and sad situation, really : /

[Martin 2BAM]

Projects like MAME, DOSBox and VMware (and other emulators/virtual machines) seem to sort it out. With newer higher-power computers, you can simulate old hardware

Nowadays you can make use of cross-platform libraries (primarily thanks to Stallman and the GNU movement) that will eventually evolve to newer platforms, and you should be able to port it easily.

With good programming techniques and abstraction you can also port it, even if the library you use is deprecated (see Doom on iPhone, it was almost unchanged).

The thing is, will Left 4 Dead (or whatever) be enjoyable in 50 years? I don't see a lot of people playing Leisure suite Larry 1 (even with the ease of DOSBox)
:3

[gunmaggot]

I dunno, a lot of people need to scratch their retro itch sometimes.  I played through Sierra's Black Cauldron a month or so ago - that is a rad adventure game that lends itself very well to replayability because it's short, open-ended and has a ton of gamey elements.  Because it was aimed mostly at kids it has very little of the mean-spiritedness of a lot of other old Sierra adventures.  I wish adventure games had gone in that direction instead of the point-and-click route.

[moi]

Java

[Martin 2BAM]

I retro-live more or less  , but when our whole generation dies, nobody is going to play super mario bros again, except in a weird underground vintage museum on pot.

[Tom Sennett]

I retro-live more or less  , but when our whole generation dies, nobody is going to play super mario bros again, except in a weird underground vintage museum on pot.

No way. People will play this, Pac-Man, and Tetris until the end of the world.

[Mikademus]

Java

Tomorrow's COBOL today!

[hatu]

The big Virtual Machines are probably the best bet. Java or Flash for example. You should be able to play the game without any changes for as long as the companies are going to be porting their players to the latest OSs and not make stupid decisions about backwards compatibility.

[Tycho Brahe]

I agree with parthon, using reusable code and libraries like opengl seems to be the way to go. Although it sounds bad, the majority of opengl tutorials I come across are over 10 years old, and still work. Generally also, developing for a computer, instead of a console or portable device will almost certainly guarantee longevity, as most pc OS distributors attempt to make sure older programs will still work. Developing for something like the iPhone however, will probably not grant longevity for your code as the life cycle and general changeability of portable machines means that the creators of them do not often take steps to ensure that legacy code works.

[Chromanoid]

The big Virtual Machines are probably the best bet. Java or Flash for example. You should be able to play the game without any changes for as long as the companies are going to be porting their players to the latest OSs and not make stupid decisions about backwards compatibility.

[Average Software]

Open source the code.  With out a doubt, this best way to keep a game alive.  If people like it enough, somebody will maintain it and port it to new systems as things become obsolete.  This is why classic id games like the old Dooms and Quakes will never die.  I can play them natively today on systems that didn't even exist when they were originally released, all because Carmack released the code.

[Mikademus]

Open source the code.  With out a doubt, this best way to keep a game alive.  If people like it enough, somebody will maintain it and port it to new systems as things become obsolete.  This is why classic id games like the old Dooms and Quakes will never die.  I can play them natively today on systems that didn't even exist when they were originally released, all because Carmack released the code.

+1

[Melly]

Carmack is a pretty awesome dude.

So far the best idea I heard is the open-source bit.

Though, since I'm currently working with Flash, it makes me wonder if working with a platform like that would be detrimental to this goal. Even if I release the source of my game a few years from now, Is it still possible it could be ported to another platform? seems like it would require a pretty big ammount of rewriting.

[Average Software]

Carmack is a pretty awesome dude.

So far the best idea I heard is the open-source bit.

Though, since I'm currently working with Flash, it makes me wonder if working with a platform like that would be detrimental to this goal. Even if I release the source of my game a few years from now, Is it still possible it could be ported to another platform? seems like it would require a pretty big ammount of rewriting.

That's a risk you take by working with non-native host platforms, which doesn't just include Flash, but also Java and .NET.

I was going to add that if you want maximum lifetime, try to stick to internationally standardized languages that are free from corporate control.  Languages like C, C++, Ada, Fortran, etc...  When you rely on something like Flash, you're counting on some corporation somewhere acting in your best interests.  I've seen numerous programs broken by Java/Flash/.NET updates, because Sun/Adobe/Microsoft decided to deprecate or change things that people relied on.  Just look back at the VB 6 fiasco for a prime example of this.

With ISO standard languages, a lot of this danger doesn't exist.  Code to the stand, and you'll probably be OK.  Standard revisions take a long time, and the deliberations are public, so you shouldn't be caught be surprise if something changes.  You can even request features if you know how to write standardese, I have two C++ extensions that I'm thinking about proposing for the next revision (C++15 or so).

[Chromanoid]

mmh there are open source implementations of the java and .net...

[bateleur]

The downside of the open source suggestion is that the chances of writing the next Doom are basically zero.

There's a huge gap between someone liking your game enough to want to play it again in ten years and someone liking your game enough to take the trouble to keep it runnable.

[Average Software]

mmh there are open source implementations of the java and .net...

Yes, but those implementations are subject to the whims of Sun and Microsoft.  Microsoft could break compatibility at any time, and there's nothing you can do about it.  This is what happened to the legions of VB6 programmers when VB.NET came out, MS basically gave them the finger and broke all their stuff.

The downside of the open source suggestion is that the chances of writing the next Doom are basically zero.

There's a huge gap between someone liking your game enough to want to play it again in ten years and someone liking your game enough to take the trouble to keep it runnable.

This is true whether your code is open or not.  At least if it's open, the possibility exists.  Without open code, someone would have to disassemble the code and try to reverse engineer it, which is much more difficult.