Hi,
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?
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?
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?
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?
And last but not least, are there any other know commercial products (games primarily) out there that has used PD as the audioengine?
Cheers! Thomas
I think the code for making PD patches proprietary is proprietary...
d.
Thomas Jeppesen wrote:
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?
(sory to bottom post Dereks reply, I lost the parent)
Thomas, the thing is not to implement a games engine in Pd, but to implement Pd in game engines. The former is foolish, trust me :)
I heard that EA have their own build called EApd
I also know that one *very* large company has Pd in R&D for their console platform.
I am also talking to some development companies and advocating Pd to some games engine manufacturers for procedural audio.
My mission is more to do with establishing an industry standard language for proc audio, being dataflow. For many reasons Millers Pd is the correct choice and almost optimal object set.
The widely held view is that the trick is to implement Pd within the existing plugin structure of current technologies.
I wouldn't bother trying to hide your work, publish it and join in the advancement of technology for everyone. Work on getting your client to take a non-exclusive license or buyout of your work and impress the value of open source technology on them. Open source is not incompatible with profitable enterprise.
A better choice for you would be Max if you must follow this road, but then you'll need to negotiate a license with Cycling74.
best regards,
Andy
On Wed, 19 Dec 2007 16:05:14 +0100 Derek Holzer derek@umatic.nl wrote:
I think the code for making PD patches proprietary is proprietary...
d.
Thomas Jeppesen wrote:
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?
-- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 138: "Retrace your steps"
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Thomas Jeppesen wrote:
Hi,
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?
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?
the first idea that comes to my mind is by "binarizing" the pd-files (that is: make the files non-human readable); and write a small converter that will revert your changes before Pd parses the file. the simplest way would probably just add a constant offset to each character, does making the file not recognizable on first glance. more sophisticated solutions would involve encryption.
but then, what do you really want to protect?
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?
creating your own version of Pd is probably the most simple way to achieve a "locked" version. another reason for this is probably to include all "external" objects into a single binary and strip all the objects not needed.
btw, "commercial" is not contradictory to "open source".
mfga,sdr IOhannes
i can't imagine how a game's sales would be in any way compromised by the audio engine being open source or not. but then again i'm not a complete **** bastard lawyer type of person.
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).
Best,
Chris.
Chris McCormick wrote:
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).
However, it is worth noting that not _all_ of Pd is BSD licensed. While all of the core is, a large number of externals are licensed under the GPL. Also, be sure to read the exact text in the BSD license distributed with Pd, as there are many variants that have different sets of requirements.
-- Russell Bryant
On Wed, 19 Dec 2007 23:49:15 -0500 Chris McCormick chris@mccormick.cx wrote:
They are risk averse and will shoot your ideas down with economic figures from years old games (gosh,
Risk aversity in games is an interesting topic in it's own right. I read somewhere that 86(96??) percent of games are deemed "failures". What other industry has this profile? Mineral/oil prospecting?!
If this is true
i) You can hardly call games a risk averse business.
ii) The profits on "successful" games must be COLOSSAL!!!!
iii) Something is terribly wrong and development needs re-balancing somehow.
Here's what we are up against....Parts of the equation leading to "same old same old crap" conservatism (and I'm largely repeating other peoples voices here...)
Games came from bedroom hackers to multi-billon industry in a decade! Talk about growing pains.
A "self cannibalisation" of an inward looking industry. Paranoid protectionism and consequent lack of skills fluidity and atrophy of intellectual impetus... (pretty harsh, but a fair view of games circa 2004, things have improved since.)
Premature compartmentalisation of roles in a forced top down design model, eg sound designer vs audio programmer or level designer vs script writer. Causes inefficiently decoupled teams.
Powerful forces trying to subvert/subsume gaming into the Hollywood linear narrative (take the games market to sell what amount to interactive films)
A very fickle marketplace.
Hostile societal and political lobbys (viz violence, political censorship, ideological engineering).
No reliable software metrics for development.
Hardware is a rapidly moving target. Some games are obsolete before they get halfway through the dev lifecycle. Hampered by inability to rapidly redepoly content on new platforms because of proprietary obstacles.
Downstream publishers destroying years of production work by insisting on encumbrances, alienating users with aggressive copy protection that makes products unusable.
So, maybe we're crazy trying to advocate disruptive new technology into that situation, but someone has to do it ;)
On Wed, 19 Dec 2007 23:49:15 -0500 Chris McCormick chris@mccormick.cx wrote:
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.
Popular glue code within game dev is lua, so Pdlua from Claude and the peeps at Goto10 seems a very useful bridge.
Another powerful tool is OSC, most useful in the prototyping stage of development. It's easy and helpful to encapsulate all your sound objects with an OSC interface to make them portable. It has the advantage of being able to run the game code and sound code on two separate machines, nice decoupling of resources.
A very simple intro to the fun of OSC in game dev http://www.obiwannabe.co.uk/tutorials/gamedev/OSC/oschooks.html
Hallo, Andy Farnell hat gesagt: // Andy Farnell wrote:
Popular glue code within game dev is lua, so Pdlua from Claude and the peeps at Goto10 seems a very useful bridge.
Btw.: Graham Wakefield and I made Vessel/lua~ [1] run on Pd: There are still some small bugs to sort out and one feature to add till a first release, but I'm very excited about this.
[1] http://www.mat.ucsb.edu/%7Ewakefield/lua%7E/lua%7E.htm
Ciao
Frank Barknecht _ ______footils.org__
On Thu, 20 Dec 2007 22:32:06 +0100 Frank Barknecht fbar@footils.org wrote:
Hallo, Andy Farnell hat gesagt: // Andy Farnell wrote:
Popular glue code within game dev is lua, so Pdlua from Claude and the peeps at Goto10 seems a very useful bridge.
Btw.: Graham Wakefield and I made Vessel/lua~ [1] run on Pd: There are still some small bugs to sort out and one feature to add till a first release, but I'm very excited about this.
Yummmm! Me too! :) Bookmarked for new year experimentation with the Pd verision. Cheers Frank,
a.
[1] http://www.mat.ucsb.edu/%7Ewakefield/lua%7E/lua%7E.htm
Ciao
Frank Barknecht _ ______footils.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Considering that I have had to deal with this legal minefield, I can say the following:
Work with Miller to understand what is covered by the BSD license (not
all of it is) There are a number of "game engine" issues which you need to address when using Pd (this is at the technical/code level) Don't worry about the patches. Any game is going to have encryption and other copy protection stuff on it.
Please don't ask me to comment on the details of how PD has been/is being used. However, if you want to talk about the theory of PD being used in games, especially on a certain game console which I care about :-) then ask away...
Note: if you are dealing with a game publisher on the legal aspects of PD, then it is likely that my company has enough legal agreements with them for me to talk about concrete uses of PD. Let me know in private email.
Mark Danks Senior Manager, Developer Support SCEA
Thomas Jeppesen jeppesen@skydebanen.net Sent by: pd-list-bounces@iem.at 12/19/2007 05:01 AM
To PD-list@iem.at cc
Subject [PD] Creating auidioengines for games using PD
Hi,
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?
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?
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?
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?
And last but not least, are there any other know commercial products (games primarily) out there that has used PD as the audioengine?
Cheers! Thomas
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
First of all, thanks to everybody who have answered to my post. It is much appreciated!
A lot of my questions have been answered – thank you all!
The reason behind these questions is, I'm a thesis student (almost finished). In my thesis I've been working with gameplay in sound, primarily within a musical context. For this purpose I've build a prototype of a music game of my own design, using PD alone to build both the game engine (imagine that Andy ;) ) and the audio engine.
Of all the game engines I've come across, none of them would have been able to do what I've been able to do in PD within a few months. This off course has to do with the very nature of advanced audio gameplay, which is relatively new in gamedesign, but as we've all seen with the rise of Guitar Hero and Sing Star, something that has become very big business. In other words, the market now seems ready for this kind of audio/music gameplay, but the technology available within the industry is not, at least not for small time developers, unless PD can be integrated within a product without to many obstacles.
Since I'm not a programmer in the traditional sense, I'd like to continue using PD as my main environment for experimenting with audio gameplay, but if it was a dead end development vise, maybe I should reconsider, because of the hard sell situation it would put me in. But fortunately your answers tells me to just continue using PD, even if certain legal issues still needs some ironing out.
Any other info or theorizing about using PD in games both legally, design wise and technically, are most welcomed since it is highly relevant to my chapter about using PD for game design in general.
Thank you all again and I hope you will all have a Merry Christmas and a Happy New Year!
Cheers! Thomas
Mark_Danks@PlayStation.Sony.Com wrote:
Considering that I have had to deal with this legal minefield, I can say the following:
Work with Miller to understand what is covered by the BSD license (not all of it is) There are a number of "game engine" issues which you need to address when using Pd (this is at the technical/code level) Don't worry about the patches. Any game is going to have encryption and other copy protection stuff on it.
Please don't ask me to comment on the details of how PD has been/is being used. However, if you want to talk about the theory of PD being used in games, especially on a certain game console which I care about :-) then ask away...
Note: if you are dealing with a game publisher on the legal aspects of PD, then it is likely that my company has enough legal agreements with them for me to talk about concrete uses of PD. Let me know in private email.
Mark Danks Senior Manager, Developer Support SCEA
*Thomas Jeppesen jeppesen@skydebanen.net* Sent by: pd-list-bounces@iem.at
12/19/2007 05:01 AM
To PD-list@iem.at cc
Subject [PD] Creating auidioengines for games using PD
Hi,
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?
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?
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?
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?
And last but not least, are there any other know commercial products (games primarily) out there that has used PD as the audioengine?
Cheers! Thomas
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
For this purpose I've build a prototype of a music game of my own design, using PD alone to build both the game engine (imagine that Andy ;) ) and the audio engine.
Great stuff!! No need to imagine though, having done it in a few different ways ;) Sorry if that seemed to preempt you with an assumption but we are possibly talking about different things when we say "game audio engine" The pitfalls of _some_ approaches are worth noting. In one sense Pd already *IS* the perfect audio engine as I've said for a long time. Having experimented with all that groundwork for 3D VR type games engines, inverse square distancing, occlusion filters, instance management, yes it can all be done in Pd. But I don't think that's Pds strength, which is why I say it's putting the cart before the horse to try and reinvent an entire "game audio engine" of the existing kind in Pd. Does that make sense? It doesn't lead to very maintainable or nice code at the level where you just need speed and robustness. That's the "game audio framework" if you like. As I see it, 90% of what existing middleware engines really do (Wwise, FMOD etc) is actually quite simple and a lot is management, (buffers, instances, resources), and they're a way to platform independent development because of all the back-end services they provide to DX10, DA or whatever. You certainly don't want to have to write that code in Pd!! What Pd brings is a very powerful abstraction layer for defining object voicings, not doing all the boring housekeeping. That's why I've said elsewhere that I think "game audio engine" in the sense of middleware apps is a misnomer. So, for large games, Pd is better seen as a component within a framework not a way to reimplement that framework. I expect most of what applies to 3D VR games applies to musical Guitar Hero type games, but there will also be some issues unique to each.
When you and I say "game audio engine" I think we are seeing the vision we share of proper dynamic/procedural audio. What many people in the industry mean by the term is different, and that's something we need to challenge.
Of all the game engines I've come across, none of them would have been able to do what I've been able to do in PD within a few months.
Yes! This is the nub. Nothing else comes close to giving the power of a dataflow development environment for audio and audio related logic. In terms of (mythical) man-months the value is astonishing. I've prototyped entire (simple) games in an afternoon.
In other words, the market now seems ready for this kind of audio/music gameplay, but the technology available within the industry is not, at least not for small time developers, unless PD can be integrated within a product without to many obstacles.
It depends what you define as obstacle. Technically it's possible and the few tough ones you'll hear talked about to do with DSP graph reconfiguration, runtime metrics, parallelism, object interfaces to physics and event structures, they are just software engineering puzzles as we consider how to do it _properly_, in an elegant and extensible way. Chris McCormick already has several examples of PDa embedded games. Of course we're all really waiting to see what Spore delivers.
The legal issues are something I don't get into, but I do know that the BSD style license makes Pd attractive to commercial developers, so that's important. One that we differ on is that protecting your code is important to you. I understand that and think the other guys have eased that fear, yes you can obfuscate/encrypt it. I take the approach that a shared library of techniques and code is very valuable to us all, which is why I have written a textbook on procedural audio that demonstrates hundreds of tricks and object models. IMHO assets are overvalued in media, it is concepts, techniques and the people who can implement them that are valuable. That's why I tear my hair when I see idiots spending millons on some dumb DRM system to protect a few crummy samples, completely ignoring the living moment of the product, the team and the audience.
Since I'm not a programmer in the traditional sense, I'd like to continue using PD as my main environment for experimenting with audio gameplay, but if it was a dead end development vise, maybe I should reconsider, because of the hard sell situation it would put me in.
I totally understand. When I moved from radio/TV and began R&D in procedural game audio looking at the so called "game audio engines" available was very disappointing. Everyone said "If you want to do game audio programming work go and learn one of the game engines". So I looked at them and thought "There has to be some hidden thing I'm not getting here..these tools are so limited, what is there to learn?!" It seemed there was a gulf between the tools like Pd and what's available on commercial game platforms. I had to research for a long time to understand the history and culture that led to such a situation (what I call the data-model). Building quality PA in dataflow is only part of what I'm up to, the rest is working very hard through advocacy and demonstration to make sure it's _not_ a dead end development route. Dataflow is the future of game audio and you can take that to the bank :)
Yeah, I spend a lot of time talking it up. That's how you get things moving.
But we need time and a strategy, there's a measured process to go through before it gets there. The biggest obstacle to dataflow procedural audio is not technical, or legal, or business politics, it's __training__. Every Joe can use protools and so there's a big pool of skills for developers.
Let's say you're a genius game writer with a concept prototype in Pd. You just want to plug it right into the console not have the entire thing rewritten in a suboptimal way that will take months. How are your second tier developers going to add content? I already had this one with a dance revolution type game I wrote (you know, jump on the dance mat in time with the beats)... it was nicely laid out and maintainable but being the only one who really understood Pd everything came back to me.
The more chaps like you go to developers and say "Hey I'm a musical game writer (or sound designer or whatever), why don't you use Pd??" the more it pushes things in the right direction. Don't let the outdated existing industry tools be an obstacle to your visions. Please, embrace the hard sell, go out there with your ideas and don't just tell people what they are, but how they should be implemented!
Another thing is, once you've been spoiled by the crack cocaine of Pd there's no going back ;) Just try reimplementing your ideas in C# using an engine like FMOD. You sit there getting frustrated knowing you could have finished it weeks ago and longing to get on with some real work... in Pd :)
Any other info or theorizing about using PD in games both legally, design wise and technically, are most welcomed since it is highly relevant to my chapter about using PD for game design in general.
Well, we could talk all day on it and I'm very happy to help you with anything that advances the role of Pd in games. Have you looked at the papers and demonstrations on obiwannabe.co.uk, the site is pretty much one big launchpad for Pd as procedural game audio, but it's more geared towards the general case of sound effects and VR than musical games. I'd certainly love to hear much more about your game and your plans to produce it. Looking forwards to reading your thesis, and if you want to write anything else to support the programme, anecdotes, observations, techniques, then I'd be happy to review or publish them in an appropriate context.
Thank you all again and I hope you will all have a Merry Christmas Happy New Year!
Cheers! Thomas
Happy holidays Thomas, and good luck with your development.
Andy
On Thu, 20 Dec 2007 15:12:07 +0100 Thomas Jeppesen jeppesen@skydebanen.net wrote:
First of all, thanks to everybody who have answered to my post. It is much appreciated!
A lot of my questions have been answered _ thank you all!
The reason behind these questions is, I'm a thesis student (almost finished). In my thesis I've been working with gameplay in sound, primarily within a musical context. For this purpose I've build a prototype of a music game of my own design, using PD alone to build both the game engine (imagine that Andy ;) ) and the audio engine.
Of all the game engines I've come across, none of them would have been able to do what I've been able to do in PD within a few months. This off course has to do with the very nature of advanced audio gameplay, which is relatively new in gamedesign, but as we've all seen with the rise of Guitar Hero and Sing Star, something that has become very big business. In other words, the market now seems ready for this kind of audio/music gameplay, but the technology available within the industry is not, at least not for small time developers, unless PD can be integrated within a product without to many obstacles.
Since I'm not a programmer in the traditional sense, I'd like to continue using PD as my main environment for experimenting with audio gameplay, but if it was a dead end development vise, maybe I should reconsider, because of the hard sell situation it would put me in. But fortunately your answers tells me to just continue using PD, even if certain legal issues still needs some ironing out.
Any other info or theorizing about using PD in games both legally, design wise and technically, are most welcomed since it is highly relevant to my chapter about using PD for game design in general.
Thank you all again and I hope you will all have a Merry Christmas and a Happy New Year!
Cheers! Thomas
Mark_Danks@PlayStation.Sony.Com wrote:
Considering that I have had to deal with this legal minefield, I can say the following:
Work with Miller to understand what is covered by the BSD license (not all of it is) There are a number of "game engine" issues which you need to address when using Pd (this is at the technical/code level) Don't worry about the patches. Any game is going to have encryption and other copy protection stuff on it.
Please don't ask me to comment on the details of how PD has been/is being used. However, if you want to talk about the theory of PD being used in games, especially on a certain game console which I care about :-) then ask away...
Note: if you are dealing with a game publisher on the legal aspects of PD, then it is likely that my company has enough legal agreements with them for me to talk about concrete uses of PD. Let me know in private email.
Mark Danks Senior Manager, Developer Support SCEA
*Thomas Jeppesen jeppesen@skydebanen.net* Sent by: pd-list-bounces@iem.at
12/19/2007 05:01 AM
To PD-list@iem.at cc
Subject [PD] Creating auidioengines for games using PD
Hi,
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?
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?
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?
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?
And last but not least, are there any other know commercial products (games primarily) out there that has used PD as the audioengine?
Cheers! Thomas
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Andy,
I just wanted to thank you for your keen interest in my topic here - It is much appreciated! I can't really reply in length here, since I'm standing with one foot in Sweden (I'm currently in Denmark) going there over the Christmas. But to make it short, the gameengine of mine isn't a fancy one, since my game is non-visual - It's about music :) So the "gameengine" in this particular case is really just simple game logic, something that PD is quite capable off :)
A textbook about procedural audio. That sounds very interesting, is it out yet?
Happy hollydays! Thomas
Andy Farnell wrote:
For this purpose I've build a prototype of a music game of my own design, using PD alone to build both the game engine (imagine that Andy ;) ) and the audio engine.
Great stuff!! No need to imagine though, having done it in a few different ways ;) Sorry if that seemed to preempt you with an assumption but we are possibly talking about different things when we say "game audio engine" The pitfalls of _some_ approaches are worth noting. In one sense Pd already *IS* the perfect audio engine as I've said for a long time. Having experimented with all that groundwork for 3D VR type games engines, inverse square distancing, occlusion filters, instance management, yes it can all be done in Pd. But I don't think that's Pds strength, which is why I say it's putting the cart before the horse to try and reinvent an entire "game audio engine" of the existing kind in Pd. Does that make sense? It doesn't lead to very maintainable or nice code at the level where you just need speed and robustness. That's the "game audio framework" if you like. As I see it, 90% of what existing middleware engines really do (Wwise, FMOD etc) is actually quite simple and a lot is management, (buffers, instances, resources), and they're a way to platform independent development because of all the back-end services they provide to DX10, DA or whatever. You certainly don't want to have to write that code in Pd!! What Pd brings is a very powerful abstraction layer for defining object voicings, not doing all the boring housekeeping. That's why I've said elsewhere that I think "game audio engine" in the sense of middleware apps is a misnomer. So, for large games, Pd is better seen as a component within a framework not a way to reimplement that framework. I expect most of what applies to 3D VR games applies to musical Guitar Hero type games, but there will also be some issues unique to each.
When you and I say "game audio engine" I think we are seeing the vision we share of proper dynamic/procedural audio. What many people in the industry mean by the term is different, and that's something we need to challenge.
Of all the game engines I've come across, none of them would have been able to do what I've been able to do in PD within a few months.
Yes! This is the nub. Nothing else comes close to giving the power of a dataflow development environment for audio and audio related logic. In terms of (mythical) man-months the value is astonishing. I've prototyped entire (simple) games in an afternoon.
In other words, the market now seems ready for this kind of audio/music gameplay, but the technology available within the industry is not, at least not for small time developers, unless PD can be integrated within a product without to many obstacles.
It depends what you define as obstacle. Technically it's possible and the few tough ones you'll hear talked about to do with DSP graph reconfiguration, runtime metrics, parallelism, object interfaces to physics and event structures, they are just software engineering puzzles as we consider how to do it _properly_, in an elegant and extensible way. Chris McCormick already has several examples of PDa embedded games. Of course we're all really waiting to see what Spore delivers.
The legal issues are something I don't get into, but I do know that the BSD style license makes Pd attractive to commercial developers, so that's important. One that we differ on is that protecting your code is important to you. I understand that and think the other guys have eased that fear, yes you can obfuscate/encrypt it. I take the approach that a shared library of techniques and code is very valuable to us all, which is why I have written a textbook on procedural audio that demonstrates hundreds of tricks and object models. IMHO assets are overvalued in media, it is concepts, techniques and the people who can implement them that are valuable. That's why I tear my hair when I see idiots spending millons on some dumb DRM system to protect a few crummy samples, completely ignoring the living moment of the product, the team and the audience.
Since I'm not a programmer in the traditional sense, I'd like to continue using PD as my main environment for experimenting with audio gameplay, but if it was a dead end development vise, maybe I should reconsider, because of the hard sell situation it would put me in.
I totally understand. When I moved from radio/TV and began R&D in procedural game audio looking at the so called "game audio engines" available was very disappointing. Everyone said "If you want to do game audio programming work go and learn one of the game engines". So I looked at them and thought "There has to be some hidden thing I'm not getting here..these tools are so limited, what is there to learn?!" It seemed there was a gulf between the tools like Pd and what's available on commercial game platforms. I had to research for a long time to understand the history and culture that led to such a situation (what I call the data-model). Building quality PA in dataflow is only part of what I'm up to, the rest is working very hard through advocacy and demonstration to make sure it's _not_ a dead end development route. Dataflow is the future of game audio and you can take that to the bank :)
Yeah, I spend a lot of time talking it up. That's how you get things moving.
But we need time and a strategy, there's a measured process to go through before it gets there. The biggest obstacle to dataflow procedural audio is not technical, or legal, or business politics, it's __training__. Every Joe can use protools and so there's a big pool of skills for developers.
Let's say you're a genius game writer with a concept prototype in Pd. You just want to plug it right into the console not have the entire thing rewritten in a suboptimal way that will take months. How are your second tier developers going to add content? I already had this one with a dance revolution type game I wrote (you know, jump on the dance mat in time with the beats)... it was nicely laid out and maintainable but being the only one who really understood Pd everything came back to me.
The more chaps like you go to developers and say "Hey I'm a musical game writer (or sound designer or whatever), why don't you use Pd??" the more it pushes things in the right direction. Don't let the outdated existing industry tools be an obstacle to your visions. Please, embrace the hard sell, go out there with your ideas and don't just tell people what they are, but how they should be implemented!
Another thing is, once you've been spoiled by the crack cocaine of Pd there's no going back ;) Just try reimplementing your ideas in C# using an engine like FMOD. You sit there getting frustrated knowing you could have finished it weeks ago and longing to get on with some real work... in Pd :)
Any other info or theorizing about using PD in games both legally, design wise and technically, are most welcomed since it is highly relevant to my chapter about using PD for game design in general.
Well, we could talk all day on it and I'm very happy to help you with anything that advances the role of Pd in games. Have you looked at the papers and demonstrations on obiwannabe.co.uk, the site is pretty much one big launchpad for Pd as procedural game audio, but it's more geared towards the general case of sound effects and VR than musical games. I'd certainly love to hear much more about your game and your plans to produce it. Looking forwards to reading your thesis, and if you want to write anything else to support the programme, anecdotes, observations, techniques, then I'd be happy to review or publish them in an appropriate context.
Thank you all again and I hope you will all have a Merry Christmas Happy New Year!
Cheers! Thomas
Happy holidays Thomas, and good luck with your development.
Andy
On Thu, 20 Dec 2007 15:12:07 +0100 Thomas Jeppesen jeppesen@skydebanen.net wrote:
First of all, thanks to everybody who have answered to my post. It is much appreciated!
A lot of my questions have been answered _ thank you all!
The reason behind these questions is, I'm a thesis student (almost finished). In my thesis I've been working with gameplay in sound, primarily within a musical context. For this purpose I've build a prototype of a music game of my own design, using PD alone to build both the game engine (imagine that Andy ;) ) and the audio engine.
Of all the game engines I've come across, none of them would have been able to do what I've been able to do in PD within a few months. This off course has to do with the very nature of advanced audio gameplay, which is relatively new in gamedesign, but as we've all seen with the rise of Guitar Hero and Sing Star, something that has become very big business. In other words, the market now seems ready for this kind of audio/music gameplay, but the technology available within the industry is not, at least not for small time developers, unless PD can be integrated within a product without to many obstacles.
Since I'm not a programmer in the traditional sense, I'd like to continue using PD as my main environment for experimenting with audio gameplay, but if it was a dead end development vise, maybe I should reconsider, because of the hard sell situation it would put me in. But fortunately your answers tells me to just continue using PD, even if certain legal issues still needs some ironing out.
Any other info or theorizing about using PD in games both legally, design wise and technically, are most welcomed since it is highly relevant to my chapter about using PD for game design in general.
Thank you all again and I hope you will all have a Merry Christmas and a Happy New Year!
Cheers! Thomas
Mark_Danks@PlayStation.Sony.Com wrote:
Considering that I have had to deal with this legal minefield, I can say the following:
Work with Miller to understand what is covered by the BSD license (not all of it is) There are a number of "game engine" issues which you need to address when using Pd (this is at the technical/code level) Don't worry about the patches. Any game is going to have encryption and other copy protection stuff on it.
Please don't ask me to comment on the details of how PD has been/is being used. However, if you want to talk about the theory of PD being used in games, especially on a certain game console which I care about :-) then ask away...
Note: if you are dealing with a game publisher on the legal aspects of PD, then it is likely that my company has enough legal agreements with them for me to talk about concrete uses of PD. Let me know in private email.
Mark Danks Senior Manager, Developer Support SCEA
*Thomas Jeppesen jeppesen@skydebanen.net* Sent by: pd-list-bounces@iem.at
12/19/2007 05:01 AM
To PD-list@iem.at cc
Subject [PD] Creating auidioengines for games using PD
Hi,
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?
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?
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?
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?
And last but not least, are there any other know commercial products (games primarily) out there that has used PD as the audioengine?
Cheers! Thomas
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Andy Farnell -
Chris McCormick -
Derek Holzer -
Frank Barknecht -
Greg -
hard off -
IOhannes m zmoelnig -
Mark_Danks＠PlayStation.Sony.Com -
Russell Bryant -
Thomas Jeppesen