because the code can't be secured, that's all. It's as easy to get the code from a .class or jar file as to eat an apple, and there is no way to hide your code.Java's performances are reaching those of c++, apis are great, everything is nice and cool... but your source will always be presented on a silver plate! Games CAN be made without problems, i think also pro-quality games are reachable... But who would do things everyone could copy/modify without problems?Only hobbyists like us....

It changes all the symbols (package names, variables, class names etc..) into random letters and/or language keywords. So when their decompiled, you get useless junk out. Better still, if they keywords, the code can't be recompiled. Overall it works as a deterant more than anything else. Also, most provide mapping tables from junk to real symbol names so that field reports can be sorted out.

All this is besides the point anyway, for many years the really important securing of code has been using paper contracts. The point being that if anyone trys to rip of your code, you sue their asses off.

In the case of games however, the code isn't really that important (since most of them are based on common engines). Its all about the feel/look/marketing.

I really hate that answer, its sums up all thats wrong about the guru mentallity associated with the ego driven software industry.

EDIT: It occurs to me this might have been a bit harsh, please ignore it and move on.

Everyone comes up with the question at one point or other, it doesn't make you any less bright or talented.

Kev

PS. This isn't a nasty comment directed at JBanes (you're great man!), its the author of that original statement that need shooting. EDIT: actually, turns out, it was JBanes. So you're the BAD BAD man!

yeah, i noticed my post was written too quickly... i was stupefied to see that i could decompile a 40$ app perfectly with just one click! i had the complete code, bam, directly, with the right name for variables and so on. I was a little amazed, effraid this could be done so easely. And nothing came into my mind how this could be avoided... This was the reason of my 'too-quick' post. Sorry guys.

PS. This isn't a nasty comment directed at JBanes (you're great man!), its the author of that original statement that need shooting. EDIT: actually, turns out, it was JBanes. So you're the BAD BAD man!

Seems someone just stuck his foot in his mouth.

Look, I realize that it's a little frightening at first when you realize that decompiling is so easy. But the truth is that you need to look at it from the bigger picture. If source was as valuable as everyone's gut reaction tells them, I'd be selling GAGE for the big bucks and nuts to the rest of you. But it isn't. The sum total of source code represents the hard work someone has done to organize their thoughts into a computer readable form.

There's no magic in doing this and it takes just as much hard work for the next guy to do it as it does for you to do it. Why do you think we have the source code for Wolfenstien, Doom, Quake, Quake II, Decent, the Build engine, etc? The authors knew they weren't giving anything valuable away. And look at what it got us. Doom and Quake are some of the heaviest modded games ever. Not to mention the fact that Doom has been ported to just about every OS capable of running it. From Linux, to Palm Pilots, to cell phones, we can play Doom anywhere we want thanks to the generousity of the coders. Not to mention the sales of these old games when people get tired of the data files that come with demos. Just think about that next time you are worried about your precious code. (Insert LOTR reference here...)

P.S. I wouldn't have payed $40 for that Applet anyway. It's simply and applet, not a component, it's an easy effect to reproduce (An array of 1000 sprites that fade out and get recycled? Sounds hard. ) and all you can use it for is to display a "neat web trick" on your website.

Edit: It occurs to me that I probably should have responded to one other point:

Quote

Everyone comes up with the question at one point or other, it doesn't make you any less bright or talented.

That's why I encourage people to use search functions. A simple search of Google Groups would have done wonders to becoming more educated on the subject. I have been known to be a bit harsh at times, but I do tend to get tired of the same question being *driven* by new coders who think they've really stumbled onto a BIG PROBLEM when a simple search would have disspelled the entire argument.

While I absolutly agree with you about the things that people get protective about, I do think your examples a bit flawed.

Most the game engines that release source, only release source after the techniques used are old hat. The modifications for things like Quake2 also didn't need access to the source, everything was provided through an almost plugin like interface by replacing gamex86.dll (at least on windows).

Surely in games, people are always trying to push the boundaries, design and build new techniques. Although, for the hobbiest this is unlikely to produce anything worth worrying about, I think the original question was really aimed as commerical games. In this case, hopefully, people are trying increadibly new things that would give the advantage in the market place. At which, it would seem to be sensible to protect the source in one way or another. I wonder if this has any input on why Cas used Jet?

Anyway, as I said, I'm sure you don't want to go through the same argument, and I do apologise for putting my foot squarly in my mouth.

I sorta used to buy into natively compiled code is more secure argument but within the last 6 months I've found: REC - Reverse Engineering Compiler. It does an amazing job! While it doesn't give my compilable source, it does give me a psudo code/assembly hybrid that was very useful for figuring out how data was obsfcuated on the dvd on a PS2 game I was putzing around with.

While a class file is still easier to reverse engeneer, the difference isn't siginificant to someone who is determined to crack your game. (Of course, that has always been true, but I didn't belive it until I tried.)

Most the game engines that release source, only release source after the techniques used are old hat. The modifications for things like Quake2 also didn't need access to the source, everything was provided through an almost plugin like interface by replacing gamex86.dll (at least on windows).

Actually, Id released ALL source for scripting, then you were supposed to modify it. Certainly that doesn't include the renderer, but it is a rather large chunk of code. The rendering engine itself, while spectacular for it's time, didn't really contain anything revolutionary. Just well optimized 3D gaming code. Most of the "secret techniques" (which were never really secret) were simply optimizations that made the code that much harder to read.

Tell you what, I'll sit you in front of the Quake I source code. How long do you think it will take you to figure it out? On the other hand, I'll sit MisterX here down with well written books and papers on 3D techniques. Who do you think will finish their 3D engine first? My opinion is that it would be a tie. If you understand the Quake code quickly, it's probably because you already understand the concepts it uses. If you understand the concepts, why do you need to look at the code?

Quote

Surely in games, people are always trying to push the boundaries, design and build new techniques. Although, for the hobbiest this is unlikely to produce anything worth worrying about, I think the original question was really aimed as commerical games. In this case, hopefully, people are trying increadibly new things that would give the advantage in the market place.

Actually, I'd hope they're trying to design fun games. Technology is a means to an end, not an end unto itself. Origin always pushed the envelope with its Wing Commander Series and made a lot of money out of it. Yet development was so expensive due to the heavy tech that Origin went bankrupt and was bought out by EA. Besides, any game programmer at the time could tell you exactly what was happening under the hood just by looking at the screen. The concepts look you right in the face! He'd probably say:

"See how the ships seem to 'jump' when turning? Or how fuzzy the fireballs get when you shoot? No magic here. They're just scaling and rotating bitmatps. Probably used precalculated lookup tables so they don't have to do it in real time."

Quote

At which, it would seem to be sensible to protect the source in one way or another.

What if I got you the source for Quake III. What would you do with it? Most commercial game developers would probably tell you that with enough time and money they could develop their own Quake III with or without access to Quake source. It really wouldn't make much of a difference other than to provide a tempting shortcut whereby they could get themselves sued. Much easier to license the code upfront and get on to developing a game to make money. Time to market! That's real value.

Not to mention that they could always *ask* Carmack how he did it. When you do something cool, you tend to want to shout it from the moutain-tops.

Quote

Let it be known, that I am a complete idiot.

Don't be so hard on yourself. I merely found it funny. I've certainly done it enough myself.

The Alien Flux java version is available, unobfuscated, for all to download, although the link isn't widely publicised. You can decompile it if you like and see how it works. Do I care? No, not really. It won't get you anywhere, although it'd be relatively easy to tweak it to submit cheat hiscores or bypass the registration check. But I reckon you'd be in that same group of customers who won't wouldn't pay for it anyway if you did that, and furthermore, I reckon that group is actually very, very small compared to the number of honest punters out there.

And as for doing anything useful with the code - well, all the useful stuff is open source anyway. The rest is just Alien Flux, and that's useless to anyone except me, really.

Surely in games, people are always trying to push the boundaries, design and build new techniques. Although, for the hobbiest this is unlikely to produce anything worth worrying about, I think the original question was really aimed as commerical games. In this case, hopefully, people are trying increadibly new things that would give the advantage in the market place. At which, it would seem to be sensible to protect the source in one way or another.

This is one of a couple of fundamental misconceptions by people who aren't professional games developers about what it is that professional GD's actually do.

Yes, you are quite right that people are trying to "push the boundaries, design new techniques". No, you are completely wrong that this has *anything* to do with source code. There was a time, long long ago, in a galaxy far away, when the difficult bit was making a particular routine run faster, and unearthing an arcane assembler trick was really difficult to do, and worth protecting. (note: I accept this is still true for some avenues in the industry, e.g. graphics-card manufacturers and some aspects of AI development; on the whole, though, it is only a tiny proportion of what studios worry about).

If you read the Gamasutra postmortems, you will quickly get a flavour of how the industry has changed (largely due to two factors: maturation and improved high-level development tools/languages).

The main problems today (in no particular order ) are: - Balancing a game design, so that it's fun, not too easy, not too hard (e.g. people like Blizzard excel at this, and spend many millions purely on balancing the gameplay) - Budgeting, planning, making realistic deadlines - ...achieving UNrealistic deadlines - Fundamentally changing an entire game when it's already 50% complete, so that you are almost writing a new game from scratch - only you don't get any extra time or budget! - Writing a demo that shows 95% of the game when you've only had 5% of the budget, because without that demo no publisher will provide ANY funding for ANY of the remaining 95% - Maintaining your sanity as an artistic/creative person (i.e. most people in the industry) when you have to remain on the same single project for multiple years. Most artistic people like to be doing new stuff all the time. - generating soft content (graphics, levels, 3D models, sounds, music, plot, subplots, etc) - improving the user-interface - improving the "game experience" (the "fun" factor) - knowing from bitter experience what should work but doesn't - although with the fast pace of change of technology, such experience only lasts a very short time

It's worth noting that all the really exciting, really valuable stuff that games developers invent is stuff you wouldn't bother looking at the source code if you wanted to steal. This is because it manifests much more obviously in the game itself.

Example 1: You play Super Metroid, or Street Fighter, or Super Mario 64, or Halo, and you (as a games developer) notice that each of those titles does some pretty unique and funky stuff with the controller. You play the game for a week, and in that time you've deduced what they've done that is so cunning (e.g. you can make good guesses at the exponential attenuation on the analog controller, or how suddenly you have to move the controller for Mario to execute a 180 degree turn, etc).

Example 2: You play Age of Empires, or Starcraft, or Metal Gear Solid and you note (if you're a games developer) the unique aspects to each, and how these contribute to gameplay. You also note each situation in which the pathfinding breaks, or does something unexpected, and you can almost immediately work out what they've done to achieve 1000 units in a game. Or you play for a week with friends, and notice what they've done to make the "tank-rush" less effective - and more importantly what they HAVEN'T done. Perhaps you play MGS and realise "here's a whole new genre of game; let's make a new title that is twice as good as MGS!".

Example 3: Either your network-coder is a grizzled old cynic who knows 99 of the top 100 gotchas of network apps development - or he's a baby-faced graduate who knows a lot of theory of OO development. You can give the graduate all the source code in the world, but until he's been burned at least 100 times, he won't be able to make ANY changes to the source code without probably completely breaking it. And he'll keep saying "but the RFC and the API docs say this ought to work!" (whereas the cynic will chuckle and point out that for the last decade no switch manufacturer has honoured the QoS bits - despite them being part of the specification).

It's things like this that are most valuable to invent, tweak, learn, and protect. But the day your game goes on the market, you've given your competitors much more of a headstart than they'd ever get if they had your source code!

Ok, I understand where you coming from, that code isn't really important and there are more important things to worry about where games are concerned. In fact, I think I said the same thing right up the top of this post.

But.. (here comes the spew)...

What if you spend 6 months architecting, designing, developing and testing a revolutionary AI library. Being the great engineer (that I'm sure everyone round here is) you build it in a beautiful OO/Java manner and its a simple API, reusable for all your companies future games. The code is thousands of lines of implementation of ideas put forth in papers at conferences.

The first game you use the wonderful new API is very simple so it only takes 6 additional months to put together.

You release it, joe bloggs hobbiest comes along, decompiles your code. Remember your API is beautifully desgined, joe and his mates find it easy to reuse. They change most of the symbol names, just enough to make it look different. Now, your company has payed 6 months of development so that every hobbiest gamer around the world can have super AI.

Now I realise, the key here was to get it to market first, and you're going to say that as soon as you released it you gave it all away to professionals anyway. Well, thats as may be, they might be a couple of months behind you..

I'm not saying there is any method to prevent people borrowing source like this, or that in most cases its that important. But where people are concerned, don't you think its worth using some form of deterant?

Interesting thing here, I'm kinda arguing against myself. Since I really like the concepts of OS, I'd like to see most APIs of this nature released seperately (ala LWJGL).

I believe I'm arguing for the sake of arguing, but if no one minds, I'm quite enjoying it..

The first game you use the wonderful new API is very simple so it only takes 6 additional months to put together.

You release it, joe bloggs hobbiest comes along, decompiles your code. Remember your API is beautifully desgined, joe and his mates find it easy to reuse. They change most of the symbol names, just enough to make it look different. Now, your company has payed 6 months of development so that every hobbiest gamer around the world can have super AI.

First and foremost, anything you develop will probably build upon what already exists. If you don't come up with it, someone else will. You'd actually be hard pressed to come up with an example of truly revolutionary technology in the game industry. Most everything done in computers was figured out in the 60's! As machines get more powerful it becomes more reasonable to apply more of that knowledge.

None the less, here's the standard MO for a company with "revolutionary" IP:

1. Patent it.2. Write a paper to establish your work.3. License it to others for $$$ or use it for legal protection as a counter-lawsuit.

And if you live in a country where [software] patents don't apply (yet...)...?! I.e. the situation for most of the world.

1. Patent it2. 3. Profit

But I don't argue against that code is not something "special" - it's the same as ideas and when you can patent "thought" then the world is really a bad place (I remember a very good swedish novel called "Kallokain" IIRC - an interesting read in todays society).

EDIT: A clarification: I'm not against patents per se - but I'm against the use of patents on software to scare people from innovating (gee, I didn't realize that company X had a patent on the use of a for loop)!