[PD] Creating auidioengines for games using PD

Chris McCormick chris at mccormick.cx
Thu Dec 20 05:49:15 CET 2007

On Wed, Dec 19, 2007 at 02:01:31PM +0100, Thomas Jeppesen wrote:
> If I wanted to use PD to build an audio-engine for a game, how would the 
> copyrights work if the game I was creating the engine for were commercial?

Pd uses the BSD license which essentially gives you the freedom to
create your own closed source version with your own modifications, as
long as you include the BSD license text, with Miller's copyright notice
in your app somewhere. You can find that text in the Pd sources and put
it in your installer or an 'about' window, or the game's documentation
for example. That is basically the only requirement of the BSD. (Please
don't take this as legal advice since I am not a lawyer, and I will not
be held responsible for anything that happens whatsoever should you
do anything I might have suggested).

> Also, and I know this is going to be sensitive to some people in this 
> community, but lets have the discussion anyway, I don't like the idea 
> about anybody being able to open the audio-engine that I have created 
> for a commercial game, as easy as they would any PD-patch out there. And 
> I'm sure the people I would be working for would hate the Idea. Is there 
> an easy or ?normal? solution to locking a patch so it can't be opened by 
> anybody?

There is no reason that they should be able to open your audio engine
(the source code).  If you integrate it with your closed source game,
and don't release the source of your modified Pd core, there is basically
nothing (short of decompiling) that they can do.

If on the other hand you are talking about the Pd patches that make up
the actual guts of the sounds, then you will have to take extra steps
to prevent people from modifying those patches. You could do this using
asymmetric cryptography. You would create a key pair and use one key
(private) to encrypt all of the patches, and then hide the second key
(public) in your source code somewhere and use that to decrypt the
patches as they are loaded. This means that nobody can create their
own patches or modify yours without the private key and hence they can't
modify your patches. I think that this is what a lot of games consoles
like the PS3 and PSP do to prevent people from running homebrew code on
their systems.

However, consider this: most games have data files that people figure out
how to hack eventually. After a while games companies started to actively
encourage this releasing by releasing level and graphics editors with
their games. Eventually they started to actually include whole APIs which
people could use to 'mod' the original game. Some of these mods have even
gone on to be commercial successes in their own right. If I were you,
I would not actively discourage people from being able to mess with the
data files (or audio engine pd-patches or whatever) since many potential
consumers of your game will see this as an asset of the game and you
will probably sell more copies because of it.

The philosophy in the games industry at large is rapidly changing.
Everyone is starting to realise that open technologies (like TCP,
HTML, mp3s, etc.) are the ones that are generally the most successful
in the market place. People like freedom. People like player created
content, and players like to create content - it makes the game more
fun. If you make your product more free, in general you will have
happier customers who pay more for your product and evangelise it to
other potential customers.

If I have convinced you of this, then your only issue will be to convince
your publisher. Unfortunately this will be a difficult task since the
mid-level manager types who will have the power are generally about 10
to 20 years behind the curve in pretty much every way. They will try
to make you cripple or remove the best things about your game, close
them up, and DRM the crap out of them. They are risk averse and will
shoot your ideas down with economic figures from years old games (gosh,
that sounds a bit bitter doesn't it ;) ).

> I know that PD has been used in the production of the music-engine for 
> Spore, but I havn't been able to find details about this particular 
> project. Does anybody know anything about it that they could share with us?

There is an article on Gamasutra about integrating Pd into your game
engine, and there was a post (I think) on my Max/MSP list about Spore
using Pd inside it, but I don't think of anything other than those bits
of info.

> I read a post from Andy Farnell on the sound design mailing list, that 
> EA had created their own version of PD for Spore, is that the only way 
> to go about it if
> you wanted to use PD in a commercial production?

Unless you run Pd as a separate process and send it network commands,
you're going to have to have to modify Pd at least a little bit to get
it integrated with your game engine. PDa will help you integrate on
low end platforms and older/handheld consoles. In the end, it's not
very difficult to do and is marginally easier to do on Windows since the
Windows build creates a .dll by default which you can trivially link
into your game (e.g. you might not have to modify much at all).




More information about the Pd-list mailing list