next »

[hatu]

Open sourcing has its problems too. Are you fine with someone taking your game and slapping their name on it and start making money? In highly competitive environments like Flash that's 100% guaranteed to happen.

[nikki]

Open sourcing has its problems too. Are you fine with someone taking your game and slapping their name on it and start making money? In highly competitive environments like Flash that's 100% guaranteed to happen.

if it's for history's sake you could open the source 10+ years later or so, not necessaryly at the same time you'd start selling it i suppose...

[Skofo]

Weird. I thought I made a post hours ago but it isn't here.

Anyway, open sourcing to extend the lifetime of your software is a great idea. It does not have to be immediately, nor do you have to open source the media.

Concerning the fact that the game in question is programmed in ActionScript: there supposedly exists an ActionScript to JavaScript converter somewhere (according to Box2DJS's page), so you may be safe once the Great Flash Exodus begins and everyone starts writing their web games in JavaScript.

[bateleur]

everyone starts writing their web games in JavaScript.

Are you... joking? Please tell me you're joking. That's too horrible to contemplate!

[s0]

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.

If the game is good enough, there's always a few dedicated fans.

[Tycho Brahe]

everyone starts writing their web games in JavaScript.

Are you... joking? Please tell me you're joking. That's too horrible to contemplate!

With html5 canvas and processing.js, thats not too much of a stupid idea...

[moi]

Anyway nothing lasts forever, all the ideas proposed can only be temporry fix.

[Average Software]

Open sourcing has its problems too. Are you fine with someone taking your game and slapping their name on it and start making money? In highly competitive environments like Flash that's 100% guaranteed to happen.

Yes, I'm fine with that, or I wouldn't release the code in the first place.  I GPL all of my code, so even if someone does that, they have to legally release their changes to the code.  If they claim ownership ("slapping their name on it") and change the copyright I can sue them for copyright infringement.

Hell, people have made money for themselves selling disks with Firefox on it, which is 100% legal.  Not everyone is in this for money.

[Overkill]

I intend to 3-clause BSD license the source I release with my finished freeware games, since I honestly don't care if someone else wants to use my code in a project of their own, and adapt or sell products with my code in it.

However, I would probably make it so there was a restrictive license on all game assets used by the code, requiring explicit permission to reuse any of the art, music, or maps in a derivative work.

This essentially meets my agenda. Do whatever you want with my codebase, but keep this license saying that you based your code off of mine, I'm not responsible if it blows up, and I am not promoting your project. You must tell me if you plan on reusing any original game content unless it's used specifically in a port of the game.

Done.

This will keep the option for people to bring the game to newer platforms, or make completely new games with my engine, and keep it away (unlikely anyways) from fan-remakes or commercial games with my assets unless I give them permission.

[Chromanoid]

maybe it even adds value when games do not last forever. to get old abandoned games to work again is a bit like being a archaeologist or restorer - a wonderful experience.

i think the best way to make games that last is to make games that are good... (wasn't this said before?)

[Kaelan]

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.

VB6 apps still work just fine. If you're talking about VB.net, it's not VB6 - it's a new language (and frankly, a terrible one that nobody has a reason to use).

Sun can only 'break' your Java app to the extent that if you rely on some undocumented nuance of say, the 1.4 release of the JVM, that undocumented nuance might change in 1.5. The same is true for the .NET CLR. If you stick to the documented parts of the APIs and specifications, the only way your app is going to 'stop working' is if you switch to a runtime that doesn't support it. Microsoft has a sparkling track record here when it comes to the CLR - I can run .NET 1.0 applications alongside .NET 2.0 applications alongside .NET 3.5 applications and they all work just fine without any changes. Sun seems to do well here but I haven't written enough Java apps to confidently say that they've never broken compat.

Sticking with a language like C/C++ is still a fairly wise choice, but I would actually caution against running into the arms of C since it's basically a glorified layer over platform-specific assembler. A carefully written .NET or Java application will remain far more portable than an equivalent C application, if only because the specifications are precise and designed with portability in mind. Say what you like about C, but it's only 'portable' in the sense that if you find a good C compiler for your target platform, you can recompile your app. Open sourcing all your code is a good option to address that, but it isn't perfect since even C/C++ have changed a lot in the past decades and so have the compilers.

The dreamlike utopia of writing your C application once and having it work on every computer invented is only a reality if you stick to the feature set supported by virtually every C compiler: adding integers and calling functions. Almost any feature you can find in C will not work on some given compiler somewhere, so portability becomes an ongoing effort. For example, the size of pointers, chars and 'int' can vary between architectures and compilers, and the behavior of various standard APIs can change as well. If you're willing to require POSIX compatibility, it becomes easier to write a "portable" C application, but the unfortunate reality is that there aren't any truly POSIX compatible operating systems in common use anymore. Neither Linux, Mac OS X or Windows actually deliver POSIX compatibility (this is partly due to problems with the POSIX spec and not those OSes).

With a platform like .NET or Java, you know up front which platforms your code will run on and you don't need to make individual tweaks to your app to support new platforms (as long as you only use standard APIs). If you want something more like C, a language like D is actually a better bet in terms of code portability due to the robustness of the spec - unfortunately, if you choose D you now have to confront the possibility of the language dying out, since it's not widely supported.

[Arne]

Also, you can design your game to be scalable, so playing it 10 years into the future adds something to the game. If the game is good and gets better, people might want to nurse the game and make sure it runs.

Elite Frontier runs very well framerate-wise in an emulator because it takes advantage of a fast processor. An RTS in the vein of Total Annihilation can allow for very high unit caps and large map sizes. A 3D shooter like Quake 1 can easily be run at a higher resolution. If you're doing a 2D game, you can think about stuff like preserving the highres source files for the graphics if you have any (I do). Then there's the obvious stuff like allowing the users to design maps, mod, etc.

It's hard to say how kind time will be to the many copies of games which sit on people's storage devices (and servers). Will SMB1.ROM outlast the physical cartridges, or will Skynet delete it?

[Average Software]

With a platform like .NET or Java, you know up front which platforms your code will run on and you don't need to make individual tweaks to your app to support new platforms (as long as you only use standard APIs).

To paraphrase Stroustrup, "Java is not cross platform, Java is a platform."

I'm not saying to use C/C++ and so on because they are "cross-platform," I'm saying that since C/C++ are internationally standardized, they're more likely to still be around in 10 or 20 years than Java or .NET are.

Hell, I don't write 100% platform neutral C++ or Ada code, I believe that's foolish.  I know how separate the platform code from the non-platform code, and I just write a new platform front-end to port to a new system.  That's the way to do it.

[Zaphos]

One thing in favor of a platform like java or .net is that you just need someone to care about *all* the work that was done for that platform as a whole enough to support it -- you don't need someone to maintain your program specifically.  So in that sense it seems a lot more likely that eg most java games will outlast most specific C/C++ games.

Taking this view to the extreme, you can develop for a platform that's already supported by portable emulators -- for example, develop snes roms, or code that runs on dosbox.  Then as long as you don't do anything too funky and people still want to run super mario or commander keen, they'll be able to run your game.

[moi]

Java is not just a new platform. It was designed from the ground up to be scalable and to ensure maximum compatibility of programs over time. Because code obsolescence has been a problem for a long time already.

[Sos]

I teach kids in primary school aged 6-9, and and when I asked them once, about a quarter to half of them played the original super mario. This is retty awesome, since the game is 25 already, almost 20 yrs older than this kids.

I don't recall playing games 20 years older than me, because there are no (except for the oscilloscope tennis thing, afaik).

WE witnessed the real birth of video games into the modern mass culture. And in 100 years time children will learn about games like SMB in schools.

[jotapeh]

Will SMB1.ROM outlast the physical cartridges, or will Skynet delete it?

Clearly the Super Mario Brothers are a threat to the supremacy of the machines

[Martin 2BAM]

"Ok kids, remember, SMB exams after the soylent green lunch break"

[agj]

I teach kids in primary school aged 6-9, and and when I asked them once, about a quarter to half of them played the original super mario.

I assure you that these kids think that the original Super Mario game is Super Mario Galaxy, or, at best, Super Mario Sunshine.

[Sos]

I teach kids in primary school aged 6-9, and and when I asked them once, about a quarter to half of them played the original super mario.

I assure you that these kids think that the original Super Mario game is Super Mario Galaxy, or, at best, Super Mario Sunshine.

That might be true.