Hi Thomas, I thought I'd also touch on the subject of sounds (or code) and encryption, since you mentioned licensing and such. Here's a question: Why are you encrypting your sounds? I don't mean "how" you encrypt them. An industry-standard like AES has been proven to work in the real world, and it can be off-loaded to specialized CPU components for very fast decryption. Inventing your own simple algorithm might not be as secure, but it might be harder to reverse-engineer than a simple call to a system default AES decrypter class. Anyway, back to the "why" part. Here are a number of reasons to encrypt your sounds: - Your source requests or requires it. - You did your own sounds and don't want others to get their hands on them. - You don't want to spoil the game by allowing users to listen to the cutscenes of levels they haven't unlocked yet.
For me, the most important reason is preventing spoilers. Yes, I wouldn't want for my custom-made music to appear on someone's podcast. But think about it: would people really put your music in their productions? Say I snooped Q9's sounds. I absolutely love its music, but if I'd use it for my own project everyone would go "Hey, that's Q9!" I wouldn't want that. Doesn't mean I don't want to have the Q9 music. I'd love to have it just to listen to. So if there was a $5 or $10 download out there featuring all of the Q9 music, I'd go for it. So that takes care of my second reason for encryption. The first reason is a different beast. If your source for sounds and music requests DRM, you better implement it. But again, such a source would probably be okay with AES encryption, even if you can easily decompile Java classes and pull out the key. So that takes care of the first reason. Now all that remains is preventing spoilers. I agree that the more secure your sounds are, the harder it would be to snatch data. For stuff you haven't unlocked yet, the only way to listen to the "spoiler sounds" would be to decrypt the sounds themselves. For plain stealing sounds you can work from memory, or even hack dsound.dll to make it dump its buffers to disk. Long story short, this bit definitely requires encryption. The question is if you should switch programming languages just to prevent a handful of people from getting to spoilers. To me it's not. Preventing access to source code you spent months of work on is another story. I'm not yet decided in that area. Cheers, Davy -----Original Message----- From: Gamers [mailto:gamers-boun...@audyssey.org] On Behalf Of Thomas Ward Sent: Saturday, December 14, 2013 13:18 To: Gamers Discussion list Subject: Re: [Audyssey] BGT, Mac and More Hi Davy, Well, the problem with XAudio2 is that a number of developers have reported it is buggy. Philip was working on a version of BGT that uses XAudio2, and found out it caused some instabilities in BGT and removed XAudio2 support for the time being. So that is why BGT does not presently support XAudio2. However, I agree for a multi-platform game there is no better option than OpenAL. You can use Joal for Java or write your own custom wrapper for the library for a decent cross-platform audio library that works on Mac, Linux, and Windows. Truth be told I am looking at using OpenAL as a replacement for DirectSound on Windows anyway just because the 3d audio is broken big time on DirectSound in Windows 7, Windows 8, and Windows 8.1. Clearly I need something else other than DirectSound, and XAudio2 is rather up in the air at this point. As far as license agreement stopping someone from reverse engineering code I just can not go with that option. To me that is like someone intentionally leaving their front door unlocked and than hanging a sign outside saying "do not enter." A person who respects you as a developer, has some decency, obviously won't reverse your code or pirate your software. However, sad to say a lot of people will not and it never hurts to add a few extra layers of security to keep the amateur wannabe crackers out of your code. At the same time I am no fan boy of a lot of the security methods used out there to secure and license software. As you say anything can be cracked, stolen, etc by the right person so adding an insane amount of security won't work. What I feel is that there has to be a fair balance between reasonable security to keep amateur wannabe crackers out while not being intrusive to legitimate customers. As you yourself said you should stop trying to create a false sense of security as nothing you try or do is perfect. The only thing you or I can do as developers is make a game good enough that people will want to buy it to own it, offer content only available to legitimate customers, and keep the cost reasonable so you make a decent income from it but not so high that people will want to turn to pirating to get it. Cheers! On 12/13/13, Davy Kager <m...@davykager.nl> wrote: > Hi, > > Yes, it definitely seems that <some language> coupled with OpenAL is > the way to go. For a Windows-only game I'd use XAudio2 (which BGT > doesn't do either), but for a multi-platform game OpenAL has a lot to > offer inspite of its quirks. It makes transitioning to iOS easier as > well, unless you go and use the Papa Engine for full binaural audio in > your iOS games. But the Papa Engine and BGT aren't free, which I > appreciate can be a bit of a problem for developers just starting out. > If you pay those $100 for BGT or your Apple iOS developer account you > practically have to come up with something that sells well in order to make > it, as you say, financially viable. > > The cross-platform applications I have developed so far worked > reasonably well on Mac, although I never made a serious effort to make > the Mac version as streamlined as the Windows version since demand was > low. This seems to be rapidly changing now. > So yes, coding your own engine in Java or C++ is a lot more work than > licensing BGT and using that, but I feel the benefits justify that > decision (provided you have the time and resources to take on such a project). > > Java's lack of security certainly stings. It's understandable if you > look at Java's history and intended use, but still... On the other > hand, the license agreement should legally stop any legitimate user > from prying. Of course enforcing a license agreement is a bit of a > toughy for indie developers. But even so, if you have an awesome > online back-end to your game, i.e. the bazaar in Entombed, users would > still have a good reason to buy the real thing. Not to mention the > whole gratitude bit: I took the time to develop for a niche market, so saying > thanks by pirating isn't very nice. > The harsh truth is that any software can be pirated if the right > people get their hands on it. > I'm especially concerned about my game's audio being stolen, partly > because I want my audio to be at least somewhat unique and partly > because it might get me into a legal corner if some kid steals my > audio and puts it up somewhere. But then again, no encryption is > going to be perfect. Java is the extreme example. You can't properly > hide your decryption key in code, and externalizing it makes it even > easier for someone to do the decryption themselves. You could > definitely store the key on a remote server and download it everytime > the game is started, but then your players can't use the game while > offline. You could also code your own implementation of AES and push > your class files through an obfuscator. That'd probably stop most > people, but it's very ugly indeed. So Java is really bad. Except > that memory dumping a BGT game also spills a lot of "interesting" > data. So yes, it securely stores sound data on disk, but it has to be > played back at some point. I guess you'd just have to make your game > good enough that people are willing to pay for it, much like true fans of a > pop star will still buy their songs instead of downloading them illegally. > Oh, and obviously the more encryption runs you put in, the slower your > game is going to be. And in the end, a determined hacker can still > get in. I think I have to watch myself and stop trying to create a > fake feeling of security. That doesn't mean I like how people can > decompile my classes, though. I suppose I have to set priorities: > rapid development or better pseudo-security. > > Cheers, > Davy > --- Gamers mailing list __ Gamers@audyssey.org If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org. You can make changes or update your subscription via the web, at http://audyssey.org/mailman/listinfo/gamers_audyssey.org. All messages are archived and can be searched and read at http://www.mail-archive.com/gamers@audyssey.org. If you have any questions or concerns regarding the management of the list, please send E-mail to gamers-ow...@audyssey.org. --- Gamers mailing list __ Gamers@audyssey.org If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org. You can make changes or update your subscription via the web, at http://audyssey.org/mailman/listinfo/gamers_audyssey.org. All messages are archived and can be searched and read at http://www.mail-archive.com/gamers@audyssey.org. If you have any questions or concerns regarding the management of the list, please send E-mail to gamers-ow...@audyssey.org.
