Re: [Audyssey] Game Engines was Heli
Hi Philip, Philip wrote: We are certainly in agreement here. Unicode conversions, memory management and all the other things are certainly a pain which I guess is why we are writing engines. My reply: Yes, in deed. I primarily began writing G3D because I got sick and tired of the nitty gritty details of C++. If I want to pass a string of text to Sapi I don't want to have to do a character string conversion to unicode all the time, or depend on Macros like _TEXT() to do it either. So what I did is my SpeakMessage() function takes a standard character string, converts it to a wchar, and then gives it to Sapi. That saves me from constantly stopping to do that character conversion myself. The engine does this automatically for me. As it should. Philip wrote: How come you decided to switch from .net to C++? What were your main reasons? My reply: Well, I stopped using .net for pretty much the same reasons you gave. It is too big, constantly being updated, too many extra dependencies, and security issues on top of it. For one thing, in 2004 Microsoft made a big todo over the fact DirectX 9.0 ships with Managed DirectX for .net developers. There were a number of books released around that time like Kickstart DirectX in C#, a Visual Basic book with similar documentation, and I was pretty impressed with the .net framework. So I wrote my first game Final Conflict in .net and had based Raceway, Mysteries of the Ancients, and other games on the .net and Managed DirectX platform. Then, out of the blue in 2007 Microsoft suddenly deprecated Managed DirectX, deprecated DirectSound, DirectPlay, and various other .net libraries I was using pretty much pulling the rug out from under me. They introduced XNA Framework for .net, but I soon discovered XAct the tool they use for packing sound files etc wasn't accessible further adding insult to injury. On top of that I started out using .net 1.1 in 2003/2004. Back then the .net framework was big, but not huge. However, between 2003 and now the .net framework has increased dramatically in size. I remember a time when the .net framework was about 99 MB, but the last time I checked the current framework is well over 300 MB. I felt it was rediculous to force my customers into downloading and installing a piece of middleware that huge. Similar frameworks like the Java runtime environment is several times smaller and is just as good as .net.Perhaps better since Sun officially supports Mac OS, Linux, and Windows compatibility between the Java runtimes where Mono, the open source .net framework, isn't completely compatible with the Microsoft .net framework. This is problematic ffor cross-platform development using .net. Finally, what really iced the cake is the issue of having wrappers for anything and everything. If you wanted to use DirectX you couldn't use it without some third-party middle ware like Managed DirectX, SlimDX, etc. This required the end user to not only update his/her copy of DirectX, but to install those third-party wrappers too. I found out pretty quick I was constantly getting technical support requests that STFC, MOTA, etc wasn't working and .net was giving them this or that runtime error. After some investigation it usually turned out to be an issue of said third-party middleware not being installed, or they installed the .net components in the incorrect order causing something to break along the way. Major pain in the butt! If all that wasn't enough to turn me off of .net the entire thing was totally unsecure. In order to protect myself from crackers I had to use a tool like Dotfuscator to obfuscate the executable to keep tools like Reflector from reverse engineering my code. Otherwise any two-bit pirate in the galaxy could dissasemble my code, turn off the security, recompile it, and pass cracked copies all over the net. Obviously, i don't want that. Plus when it comes to security there is a licensing tool, XHEO, that is suppose to be first-rate for .net developers. Well, I tried said library in my games and did some background research on the tool. Bad, bad, bad. As it turns out many companies, top programmers, have given negative reviews for this licensing library. No wonder. A google on XHEO cracks will turn up all kinds of quick and dirty ways to bypass XHEO security putting products like Rail Racer at serious risk if anyone decides to use any of the cracks floating around the internet for XHEO. Obviously, I took one look at that and said, no way. To make a long story short while I think C# .net is easy, I like the language itself, there are some serious drawbacks that make it less than ideal. Poor security, the .net framework is too large, too many dependencies, etc make it impractical for serious software development. Cheers! --- 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
Re: [Audyssey] Game Engines was Heli
Hi Thomas, We are certainly in agreement here. Unicode conversions, memory management and all the other things are certainly a pain which I guess is why we are writing engines. Smile. Luckily AngelScript has built in garbage collection so I didn't have to worry about that part, but I did have to write a small converter function from char* to WCHAR* etc. Not a big deal if it is called behind the scenes by the scripting engine but if you need to actively use it while programming, that's not so good. As for .net, I dislike it for a few reasons. First of all, it is huge. Huge, bulky, and constantly being updated so you need to download new versions of the thing. There is no reason why a few programming components should be that large, in my opinion. Granted Windows Vista and above are including .net, but then there is the issue of extra dependencies, like to play certain games you need to install not only .net but also this extra wrapper, and then a wrapper for that wrapper. Not something I'll cheer for. When I download a game, I just want it to run. I don't want to care about what it uses internally. See my drift? I also don't like the fact that .net programs are so easy to reverse engineer, and to protect yourself you need to get yet another extra add-on. Not nice. Oh I don't have a problem that a high level language compiles into mid-level byte code, .net does it and so does AngelScript and Lua and what have you, but the environment should take measures to secure the byte code. I use strong encryption to protect mine in BGT. Oh I'm sure it can be cracked, but at least I am trying and not making people get an upgrade just to have basic security features. How come you decided to switch from .net to C++? What were your main reasons? Kind regards, Philip Bennefall - Original Message - From: Thomas Ward thomasward1...@gmail.com To: phi...@blastbay.com; Gamers Discussion list gamers@audyssey.org Sent: Friday, January 28, 2011 4:40 AM Subject: Re: [Audyssey] Game Engines was Heli Hi Philip, You definitely have a point. Although, I know C++ fairly well myself I don't like using it as much as something like C# .NET just because its a little too low-level for my liking. As author Jesse Liberty put it in his book Teach Yourself C# .net in 21 Days, going back to C++ is like pulling teeth. He has a very good point as C# .net via the .NET Framework wraps all that low-level stuff in a high-level interface. For example, as you know and I know, a lot of the Windows API functions take Unicode character strings. Well, if you have a lot of anci strings you have to convert them to an unicode wide character string before passing them to the API function. That's a pain in the butt. In .net languages you don't have to worry about that problem because the System::String class can convert between ansci and unicode quite easily. Then, there is the issue of memory management and garbage collection. To be honest the garbage collecter is one of the strong advantages to using .net languages rather than C++. With C++ you are on your own unless you write your own garbage collecter to manage garbage collection in the background. Anyway, I agree with you. For various reasons writing games in C++ is a pain. There is no doubt about that. Using a scripting language like Angelscript or using a .net language as a high-level interface is obviously a much easier solution all things considered. Although, I'm curious to know why you don't like .net. There is a lot i personally like about it, and for Windows programming it makes my life as a programmer much much easier. There is also Mono, a Mac/Linux implamentation of .net, which really makes cross-platform development fairly straight forward for a lot of apps. As for the BGT documentation I can't honestly remember when the last time I looked at them was. It was well before 1.0 came out. Maybe beta 3 or beta 4. Something along that lines. As you said, a lot has changed since then, and I should have looked before saying what I said. Cheers! On 1/27/11, Philip Bennefall phi...@blastbay.com wrote: Hi Thomas, I don't know when you last viewed the BGT documentation but until fairly recently, the more advanced object oriented parts of the language were not covered at all in the tutorial. AngelScript has inheritance, polymorphism through interfaces, overloaded functions and class operators, and even such things as function pointers. So while not quite a programming language it comes very close while stil being extremely simple, and I would never go back to writing actualg ame logic in C++ again. I'm all for using C++ where speed/performance is concerned, but equally as convinced that high level game logic should be written in a high level language. And since I am not a fan of .net, I ended up using a scripting solution. This way I don't even have to initialize anything, no need to open a device, set up DirectInput or even worry about creating
Re: [Audyssey] Game Engines was Heli
Hi Philip, Yeah, I do see what you mean. For one thing we have taken two completely different approaches to the same thing. Both have advantages and disadvantages. For example, as I understand BGT what you have done is basically written a piece of middleware that wraps DirectSound, DirectInput, Sapi, ENet, etc and then registered the functionality of BGT with Angelscript allowing someone to script a game in Angelscript and depend on your middleware to handle all the low level stuff like input, speech output, sound, networking, and various other things you have built into BGT. Am I right? Well, my approach is quite a bit different. As I mentioned before originally when I wrote Genesis 3D, AKA G3D.dll, It was written in C# .NET and wrapped Microsoft's Managed DirectX, Sapi, as well as provided a number of custom .NET classes that provided an API for quick and easy game creation using the various .NET languages like C#, C++, and Visual Basic. However, once I found out that Managed DirectX was buggy and Microsoft's XNA Framework .for .NET is largely inaccessible I decided to port the engine to C++ and use the various APIs directly rather than writing a piece of middleware based on other middle ware like Managed DirectX. The current Genesis engine is written in C++, is fully object oriented, and uses a managed C++ design model. The reason I wrote it as managed code is because in theory I can take the G3D.dll library include it in A C# .NET or VB .NET project import the library and have input, speech, networking, advanced 3d calculations, etc ready to go. All I need to do is initialize the class or classes I wish to use. For example, although Streemway is not managed C++, I have written a managed wrapper for it that I can use in a Visual Basic .NET applike this. ' Import the G3D namespace import G3D ' Declare an audio class object Private audio As Audio ' Initialize audio ' and play a sound Static Sub Main() if audio.InitializeAudio(Window.IsWindowHandle()) == false then ' Show error message Close() End If ' Load and play sound audio.SoundOpen (0, fire.wav) audio.SoundPlay (0, false) End Sub Okay, this is a bit of an over simplification since I left out all of the form initialization code etc but you get the point of how easy it would be for a Visual Basic programmer to include my engine into a standard .NET application and begin using it right away to build games. Where you use something like Angelscript for programming my design is more flexable. I can obviously use C++, since that is the language the engine is written in, but I can also plug it into any .NET language like C# .NET or Visual Basic .NET and use that to build games. This would essentually give the end user a choice of language or languages to use when building games. As a long time .NET developer I happen to know that C# is hundreds of times easier than C++ and is just as good, maybe better, than using something like Angelscript. If someone like Jim Kitchen decided to upgrade to VB .NET rather than using Visual Basic 6 he could in theory use my engine to access DirectSound, DirectInput, Sapi, all via my engine in .NET. So the choice of programming language is certainly one advantage I can see as a plus here. Another advantage is base classes. I have been adding core data classes for a number of common game objects you might encounter. Since the base classes are there you can use inheritence to extend or expand the functionality of the classes without having to rewrite anything. For example, take the player class. It has all of the normal things you would expect to find like health, location, direction, point of view, etc. However, by itself it couldn't be used to create a special character like a wizard. No problem create your own class and inherit the player class like this. import G3D Class Wizard Inherits Player ' Add wizard specific code here End Class This gives a game developer all the primary classes they need to work with, but gives them the flexability to extend the classes and functionality as needed. Not to mention the fact that doing it this way using C++, C#, or VB .NET gives you all the advanced functionality of object oriented design like pollimorphism, inheritance, etc. When I was trying out BGT one of the things I didn't like as it lacked a number of advanced language features I'm personally use to having when programming. Finally, there is he issue of cross-platform support. At this current time I have elected not to port the Genesis engine to Mac OS or to Linux just because of the effort in volved plus I've discovered to do it right I need to use OS specific libraries and toolkits. All the same if I were to create this port it would be a definite advantage over BGT as the same engine could be used on more than one platform. In terms of disadvantages Genesis 3D was designed primarily to target game developers with some programming skills in C++, C#, or VB .NET. This enables someone to
Re: [Audyssey] Game Engines was Heli
The one thing I really have liked about angel script is how similar it is to other languages. I switched over to BGT from vb6. It was a bit of a hassle at first, but after about 4 months with it I became very fluent. Around that time, I had to start doing some PHP work for my job, and I'm finding that the syntax between angelscript and php has some similarities which has made jumping between the languages much simpler. If I had the option to keep going in vb.net I wouldn't have challenged myself and learned something knew which would not only help my games, but my work as well. -Original Message- From: gamers-boun...@audyssey.org [mailto:gamers-boun...@audyssey.org] On Behalf Of Thomas Ward Sent: Thursday, January 27, 2011 5:06 AM To: Philip Bennefall; Gamers Discussion list Subject: Re: [Audyssey] Game Engines was Heli Hi Philip, Yeah, I do see what you mean. For one thing we have taken two completely different approaches to the same thing. Both have advantages and disadvantages. For example, as I understand BGT what you have done is basically written a piece of middleware that wraps DirectSound, DirectInput, Sapi, ENet, etc and then registered the functionality of BGT with Angelscript allowing someone to script a game in Angelscript and depend on your middleware to handle all the low level stuff like input, speech output, sound, networking, and various other things you have built into BGT. Am I right? Well, my approach is quite a bit different. As I mentioned before originally when I wrote Genesis 3D, AKA G3D.dll, It was written in C# .NET and wrapped Microsoft's Managed DirectX, Sapi, as well as provided a number of custom .NET classes that provided an API for quick and easy game creation using the various .NET languages like C#, C++, and Visual Basic. However, once I found out that Managed DirectX was buggy and Microsoft's XNA Framework .for .NET is largely inaccessible I decided to port the engine to C++ and use the various APIs directly rather than writing a piece of middleware based on other middle ware like Managed DirectX. The current Genesis engine is written in C++, is fully object oriented, and uses a managed C++ design model. The reason I wrote it as managed code is because in theory I can take the G3D.dll library include it in A C# .NET or VB .NET project import the library and have input, speech, networking, advanced 3d calculations, etc ready to go. All I need to do is initialize the class or classes I wish to use. For example, although Streemway is not managed C++, I have written a managed wrapper for it that I can use in a Visual Basic .NET applike this. ' Import the G3D namespace import G3D ' Declare an audio class object Private audio As Audio ' Initialize audio ' and play a sound Static Sub Main() if audio.InitializeAudio(Window.IsWindowHandle()) == false then ' Show error message Close() End If ' Load and play sound audio.SoundOpen (0, fire.wav) audio.SoundPlay (0, false) End Sub Okay, this is a bit of an over simplification since I left out all of the form initialization code etc but you get the point of how easy it would be for a Visual Basic programmer to include my engine into a standard .NET application and begin using it right away to build games. Where you use something like Angelscript for programming my design is more flexable. I can obviously use C++, since that is the language the engine is written in, but I can also plug it into any .NET language like C# .NET or Visual Basic .NET and use that to build games. This would essentually give the end user a choice of language or languages to use when building games. As a long time .NET developer I happen to know that C# is hundreds of times easier than C++ and is just as good, maybe better, than using something like Angelscript. If someone like Jim Kitchen decided to upgrade to VB .NET rather than using Visual Basic 6 he could in theory use my engine to access DirectSound, DirectInput, Sapi, all via my engine in .NET. So the choice of programming language is certainly one advantage I can see as a plus here. Another advantage is base classes. I have been adding core data classes for a number of common game objects you might encounter. Since the base classes are there you can use inheritence to extend or expand the functionality of the classes without having to rewrite anything. For example, take the player class. It has all of the normal things you would expect to find like health, location, direction, point of view, etc. However, by itself it couldn't be used to create a special character like a wizard. No problem create your own class and inherit the player class like this. import G3D Class Wizard Inherits Player ' Add wizard specific code here End Class This gives a game developer all the primary classes they need to work with, but gives them the flexability to extend the classes and functionality as needed. Not to mention the fact that doing it this way using C++, C#, or VB .NET
Re: [Audyssey] Game Engines was Heli
Hi Thomas, Yes, I can see where you are coming from in terms of flexibility of languages. BGT could also be made into a dll relatively easily, but I have not yet had a lot of requests for this and since I am comfortable with C++ syntax for my own development, AngelScript was a good choice for me. AngelScript does support polymorphism through something called interfaces, as well as normal single inheritance. I primarily wrote BGT for my own use, and I wanted an all in one solution that was portable and that I could take with me on a flash drive for example with no complicated installations. Code::Blocks and Visual Studio are horrible to install, if you ask me. BGT can be taken anywhere, and you can run your scripts even without actually installing the engine; it works perfectly if distributed in a zip file on a USB memory stick. This is one of the advantages I can see with a dedicated solution rather than a piece of middleware, though as we have already established both of these have their advantages and disadvantages. Kind regards, Philip Bennefall - Original Message - From: Thomas Ward thomasward1...@gmail.com To: phi...@blastbay.com; Gamers Discussion list gamers@audyssey.org Sent: Thursday, January 27, 2011 12:05 PM Subject: Re: [Audyssey] Game Engines was Heli Hi Philip, Yeah, I do see what you mean. For one thing we have taken two completely different approaches to the same thing. Both have advantages and disadvantages. For example, as I understand BGT what you have done is basically written a piece of middleware that wraps DirectSound, DirectInput, Sapi, ENet, etc and then registered the functionality of BGT with Angelscript allowing someone to script a game in Angelscript and depend on your middleware to handle all the low level stuff like input, speech output, sound, networking, and various other things you have built into BGT. Am I right? Well, my approach is quite a bit different. As I mentioned before originally when I wrote Genesis 3D, AKA G3D.dll, It was written in C# .NET and wrapped Microsoft's Managed DirectX, Sapi, as well as provided a number of custom .NET classes that provided an API for quick and easy game creation using the various .NET languages like C#, C++, and Visual Basic. However, once I found out that Managed DirectX was buggy and Microsoft's XNA Framework .for .NET is largely inaccessible I decided to port the engine to C++ and use the various APIs directly rather than writing a piece of middleware based on other middle ware like Managed DirectX. The current Genesis engine is written in C++, is fully object oriented, and uses a managed C++ design model. The reason I wrote it as managed code is because in theory I can take the G3D.dll library include it in A C# .NET or VB .NET project import the library and have input, speech, networking, advanced 3d calculations, etc ready to go. All I need to do is initialize the class or classes I wish to use. For example, although Streemway is not managed C++, I have written a managed wrapper for it that I can use in a Visual Basic .NET applike this. ' Import the G3D namespace import G3D ' Declare an audio class object Private audio As Audio ' Initialize audio ' and play a sound Static Sub Main() if audio.InitializeAudio(Window.IsWindowHandle()) == false then ' Show error message Close() End If ' Load and play sound audio.SoundOpen (0, fire.wav) audio.SoundPlay (0, false) End Sub Okay, this is a bit of an over simplification since I left out all of the form initialization code etc but you get the point of how easy it would be for a Visual Basic programmer to include my engine into a standard .NET application and begin using it right away to build games. Where you use something like Angelscript for programming my design is more flexable. I can obviously use C++, since that is the language the engine is written in, but I can also plug it into any .NET language like C# .NET or Visual Basic .NET and use that to build games. This would essentually give the end user a choice of language or languages to use when building games. As a long time .NET developer I happen to know that C# is hundreds of times easier than C++ and is just as good, maybe better, than using something like Angelscript. If someone like Jim Kitchen decided to upgrade to VB .NET rather than using Visual Basic 6 he could in theory use my engine to access DirectSound, DirectInput, Sapi, all via my engine in .NET. So the choice of programming language is certainly one advantage I can see as a plus here. Another advantage is base classes. I have been adding core data classes for a number of common game objects you might encounter. Since the base classes are there you can use inheritence to extend or expand the functionality of the classes without having to rewrite anything. For example, take the player class. It has all of the normal things you would expect to find like health, location, direction, point of view, etc. However
Re: [Audyssey] Game Engines was Heli
Hi Philip, Hmmm...Well, my opinion here was pretty much based on viewing the BGT documentation and a brief glance at the Angelscript docs. It just seamed while Angelscript is powerful as a scripting language it seamed to me to be somewhat limited compared to a full blown programming language in some respects. However, in an engine like BGT it doesn't have to be a full blown programming language to get the job done. As for Visual Studio, Codeblocks, etc you are absolutely right. Besides having to install the IDES, which is a pain in the butt by themselves, there are all the various SDKs you need like the .NET Framework or the Windows Platform SDK. Either one of those will eat a huge chunk of your hard drive space in and of themselves. That's one reason I decided to create G3D as a dll file. Once I get it stable and ready for redistirbution other than general upgrades most of the time i won't nneed the Windos Platform SDK, DirectX SDK, or any of that since my library will handle that stuff for me. However, there are advantages to something like BGT that can fit on a thunb drive without any external compilers, IDES, etc. hard to say which I like better. Smile. On 1/27/11, Philip Bennefall phi...@blastbay.com wrote: Hi Thomas, Yes, I can see where you are coming from in terms of flexibility of languages. BGT could also be made into a dll relatively easily, but I have not yet had a lot of requests for this and since I am comfortable with C++ syntax for my own development, AngelScript was a good choice for me. AngelScript does support polymorphism through something called interfaces, as well as normal single inheritance. I primarily wrote BGT for my own use, and I wanted an all in one solution that was portable and that I could take with me on a flash drive for example with no complicated installations. Code::Blocks and Visual Studio are horrible to install, if you ask me. BGT can be taken anywhere, and you can run your scripts even without actually installing the engine; it works perfectly if distributed in a zip file on a USB memory stick. This is one of the advantages I can see with a dedicated solution rather than a piece of middleware, though as we have already established both of these have their advantages and disadvantages. Kind regards, Philip Bennefall --- 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.
Re: [Audyssey] Game Engines was Heli
Hi Liam, Well, that is one of the main reasons I generally tell new programmers to try a language like Java, C#, C++, etc that use a c-style syntax and programming methodology. What you learn from one can most generally be applied to another programming language. For example, when I started learning C-Sharp in 2003 I was already quite familiar with Java and C++. With my previous experience and training it made learning C-Sharp a snap because C-Sharp is extremely similar to Java in some respects. Were I a Visual Basic 6 programmer the transition would have been much more difficult since Visual Basic and C-Sharp had little in common. With Angelscript, as you pointed out, it does use a c-style syntax and methodology. Coming from a Visual Basic background the learning curve is steeper. However, if you learn Angelscript a lot of the syntax and so on will carry over to Java, C-Sharp, C++, Perl, Flash, and so on making your transition easier in the long run. Cheers! On 1/27/11, Liam Erven liamer...@gmail.com wrote: The one thing I really have liked about angel script is how similar it is to other languages. I switched over to BGT from vb6. It was a bit of a hassle at first, but after about 4 months with it I became very fluent. Around that time, I had to start doing some PHP work for my job, and I'm finding that the syntax between angelscript and php has some similarities which has made jumping between the languages much simpler. If I had the option to keep going in vb.net I wouldn't have challenged myself and learned something knew which would not only help my games, but my work as well. --- 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.
Re: [Audyssey] Game Engines was Heli
Hi Thomas, I don't know when you last viewed the BGT documentation but until fairly recently, the more advanced object oriented parts of the language were not covered at all in the tutorial. AngelScript has inheritance, polymorphism through interfaces, overloaded functions and class operators, and even such things as function pointers. So while not quite a programming language it comes very close while stil being extremely simple, and I would never go back to writing actualg ame logic in C++ again. I'm all for using C++ where speed/performance is concerned, but equally as convinced that high level game logic should be written in a high level language. And since I am not a fan of .net, I ended up using a scripting solution. This way I don't even have to initialize anything, no need to open a device, set up DirectInput or even worry about creating the window or setting up the timer threading model, all this is done behind the scenes for you. Similarly, everything is properly destroyed even if a script exception occurs. Kind regards, Philip Bennefall - Original Message - From: Thomas Ward thomasward1...@gmail.com To: phi...@blastbay.com; Gamers Discussion list gamers@audyssey.org Sent: Thursday, January 27, 2011 4:42 PM Subject: Re: [Audyssey] Game Engines was Heli Hi Philip, Hmmm...Well, my opinion here was pretty much based on viewing the BGT documentation and a brief glance at the Angelscript docs. It just seamed while Angelscript is powerful as a scripting language it seamed to me to be somewhat limited compared to a full blown programming language in some respects. However, in an engine like BGT it doesn't have to be a full blown programming language to get the job done. As for Visual Studio, Codeblocks, etc you are absolutely right. Besides having to install the IDES, which is a pain in the butt by themselves, there are all the various SDKs you need like the .NET Framework or the Windows Platform SDK. Either one of those will eat a huge chunk of your hard drive space in and of themselves. That's one reason I decided to create G3D as a dll file. Once I get it stable and ready for redistirbution other than general upgrades most of the time i won't nneed the Windos Platform SDK, DirectX SDK, or any of that since my library will handle that stuff for me. However, there are advantages to something like BGT that can fit on a thunb drive without any external compilers, IDES, etc. hard to say which I like better. Smile. On 1/27/11, Philip Bennefall phi...@blastbay.com wrote: Hi Thomas, Yes, I can see where you are coming from in terms of flexibility of languages. BGT could also be made into a dll relatively easily, but I have not yet had a lot of requests for this and since I am comfortable with C++ syntax for my own development, AngelScript was a good choice for me. AngelScript does support polymorphism through something called interfaces, as well as normal single inheritance. I primarily wrote BGT for my own use, and I wanted an all in one solution that was portable and that I could take with me on a flash drive for example with no complicated installations. Code::Blocks and Visual Studio are horrible to install, if you ask me. BGT can be taken anywhere, and you can run your scripts even without actually installing the engine; it works perfectly if distributed in a zip file on a USB memory stick. This is one of the advantages I can see with a dedicated solution rather than a piece of middleware, though as we have already established both of these have their advantages and disadvantages. Kind regards, Philip Bennefall --- 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.
Re: [Audyssey] Game Engines was Heli
HI Phillip, Ah...so C++ does not have interfaces? Is there a similar concept there? Best Regards, Hayden -Original Message- From: gamers-boun...@audyssey.org [mailto:gamers-boun...@audyssey.org] On Behalf Of Philip Bennefall Sent: Thursday, January 27, 2011 10:09 AM To: Gamers Discussion list Subject: Re: [Audyssey] Game Engines was Heli Hi Thomas, I don't know when you last viewed the BGT documentation but until fairly recently, the more advanced object oriented parts of the language were not covered at all in the tutorial. AngelScript has inheritance, polymorphism through interfaces, overloaded functions and class operators, and even such things as function pointers. So while not quite a programming language it comes very close while stil being extremely simple, and I would never go back to writing actualg ame logic in C++ again. I'm all for using C++ where speed/performance is concerned, but equally as convinced that high level game logic should be written in a high level language. And since I am not a fan of .net, I ended up using a scripting solution. This way I don't even have to initialize anything, no need to open a device, set up DirectInput or even worry about creating the window or setting up the timer threading model, all this is done behind the scenes for you. Similarly, everything is properly destroyed even if a script exception occurs. Kind regards, Philip Bennefall - Original Message - From: Thomas Ward thomasward1...@gmail.com To: phi...@blastbay.com; Gamers Discussion list gamers@audyssey.org Sent: Thursday, January 27, 2011 4:42 PM Subject: Re: [Audyssey] Game Engines was Heli Hi Philip, Hmmm...Well, my opinion here was pretty much based on viewing the BGT documentation and a brief glance at the Angelscript docs. It just seamed while Angelscript is powerful as a scripting language it seamed to me to be somewhat limited compared to a full blown programming language in some respects. However, in an engine like BGT it doesn't have to be a full blown programming language to get the job done. As for Visual Studio, Codeblocks, etc you are absolutely right. Besides having to install the IDES, which is a pain in the butt by themselves, there are all the various SDKs you need like the .NET Framework or the Windows Platform SDK. Either one of those will eat a huge chunk of your hard drive space in and of themselves. That's one reason I decided to create G3D as a dll file. Once I get it stable and ready for redistirbution other than general upgrades most of the time i won't nneed the Windos Platform SDK, DirectX SDK, or any of that since my library will handle that stuff for me. However, there are advantages to something like BGT that can fit on a thunb drive without any external compilers, IDES, etc. hard to say which I like better. Smile. On 1/27/11, Philip Bennefall phi...@blastbay.com wrote: Hi Thomas, Yes, I can see where you are coming from in terms of flexibility of languages. BGT could also be made into a dll relatively easily, but I have not yet had a lot of requests for this and since I am comfortable with C++ syntax for my own development, AngelScript was a good choice for me. AngelScript does support polymorphism through something called interfaces, as well as normal single inheritance. I primarily wrote BGT for my own use, and I wanted an all in one solution that was portable and that I could take with me on a flash drive for example with no complicated installations. Code::Blocks and Visual Studio are horrible to install, if you ask me. BGT can be taken anywhere, and you can run your scripts even without actually installing the engine; it works perfectly if distributed in a zip file on a USB memory stick. This is one of the advantages I can see with a dedicated solution rather than a piece of middleware, though as we have already established both of these have their advantages and disadvantages. Kind regards, Philip Bennefall --- 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.
Re: [Audyssey] Game Engines was Heli
Hi Philip, You definitely have a point. Although, I know C++ fairly well myself I don't like using it as much as something like C# .NET just because its a little too low-level for my liking. As author Jesse Liberty put it in his book Teach Yourself C# .net in 21 Days, going back to C++ is like pulling teeth. He has a very good point as C# .net via the .NET Framework wraps all that low-level stuff in a high-level interface. For example, as you know and I know, a lot of the Windows API functions take Unicode character strings. Well, if you have a lot of anci strings you have to convert them to an unicode wide character string before passing them to the API function. That's a pain in the butt. In .net languages you don't have to worry about that problem because the System::String class can convert between ansci and unicode quite easily. Then, there is the issue of memory management and garbage collection. To be honest the garbage collecter is one of the strong advantages to using .net languages rather than C++. With C++ you are on your own unless you write your own garbage collecter to manage garbage collection in the background. Anyway, I agree with you. For various reasons writing games in C++ is a pain. There is no doubt about that. Using a scripting language like Angelscript or using a .net language as a high-level interface is obviously a much easier solution all things considered. Although, I'm curious to know why you don't like .net. There is a lot i personally like about it, and for Windows programming it makes my life as a programmer much much easier. There is also Mono, a Mac/Linux implamentation of .net, which really makes cross-platform development fairly straight forward for a lot of apps. As for the BGT documentation I can't honestly remember when the last time I looked at them was. It was well before 1.0 came out. Maybe beta 3 or beta 4. Something along that lines. As you said, a lot has changed since then, and I should have looked before saying what I said. Cheers! On 1/27/11, Philip Bennefall phi...@blastbay.com wrote: Hi Thomas, I don't know when you last viewed the BGT documentation but until fairly recently, the more advanced object oriented parts of the language were not covered at all in the tutorial. AngelScript has inheritance, polymorphism through interfaces, overloaded functions and class operators, and even such things as function pointers. So while not quite a programming language it comes very close while stil being extremely simple, and I would never go back to writing actualg ame logic in C++ again. I'm all for using C++ where speed/performance is concerned, but equally as convinced that high level game logic should be written in a high level language. And since I am not a fan of .net, I ended up using a scripting solution. This way I don't even have to initialize anything, no need to open a device, set up DirectInput or even worry about creating the window or setting up the timer threading model, all this is done behind the scenes for you. Similarly, everything is properly destroyed even if a script exception occurs. Kind regards, Philip Bennefall --- 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.
Re: [Audyssey] Game Engines was Heli
Except that opensource software is supposed to be recognized as such by folks who use it. Too often, I've found programs that use opensource software, then ignore the license requirements which state that they should, can, or must mention in their docs that they are using said piece of software in their programs. I've also seen blatent commercial rip-offs of opensource products that are obviously nothing more than the opensource program repackaged, and distributed as their own product, when this is clearly not the case. That kind of exploitation is illegal, but bringing anyone to task for such things is rough, and expensive, and usually doesn't happen, and the exploiters know this, which is why they do it. For example, nvda is free and opensource, I saw a company (3 or 4 years ago) selling a screen reader of their own, which was clearly nvda, but they had renamed it, and charged $250 for it. That is the kind of thing that is not allowed with opensource products. Most opensource products (especially libraries) request that you mention them in your program documentation, but some of them don't require this, simply ask that it be done, but don't demand it. My own opinion, is that if someone is using a product, especially if it was something they're using for profit, the least they can do is acknowledge where said shortcuts came from, which is generally accepted as good and honest practice in the opensource community. It's mind boggling how many times I see programs using opensource components, and there's no mention of such anywhere in the program docs. Open source is free as in free to use, not free as in free to steal and make your own. Too many commercial entities forget this point, and just rip off opensource to line their own pockets, and that's really a shame. --- 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.
Re: [Audyssey] Game Engines was Heli
Hi Travis, Here are my two cents on this. I certainly agree that one should give credit where credit is due, but what I don't agree with as a whole on the open source market is how a lot of libraries force you to put in a lot of legal mumbo jumbo in your documentation rather than just an acknowledgement and a link to their website etc. The lgpl is a great example, there you have to include a long section on how they don't accept warranty etc. On top of this, since I am making an engine, the use of many libraries would force my end users to include the same legal garbage in the game that they make with my engine. I'm not having that, so I have intentionally chosen libraries that don't require you to put credits in the documentation which means that I am free to lay them out in a way that suits the format of my application and also to not force my users to include anything to do with my internal libraries in their game manuals. The bottom line is, I don't mind giving credit but I won't use libraries that strictly enforce this. Kind regards, Philip Bennefall - Original Message - From: Travis Siegel tsie...@lothlorien.nfbcal.org To: gamers@audyssey.org Sent: Wednesday, January 26, 2011 9:39 AM Subject: Re: [Audyssey] Game Engines was Heli Except that opensource software is supposed to be recognized as such by folks who use it. Too often, I've found programs that use opensource software, then ignore the license requirements which state that they should, can, or must mention in their docs that they are using said piece of software in their programs. I've also seen blatent commercial rip-offs of opensource products that are obviously nothing more than the opensource program repackaged, and distributed as their own product, when this is clearly not the case. That kind of exploitation is illegal, but bringing anyone to task for such things is rough, and expensive, and usually doesn't happen, and the exploiters know this, which is why they do it. For example, nvda is free and opensource, I saw a company (3 or 4 years ago) selling a screen reader of their own, which was clearly nvda, but they had renamed it, and charged $250 for it. That is the kind of thing that is not allowed with opensource products. Most opensource products (especially libraries) request that you mention them in your program documentation, but some of them don't require this, simply ask that it be done, but don't demand it. My own opinion, is that if someone is using a product, especially if it was something they're using for profit, the least they can do is acknowledge where said shortcuts came from, which is generally accepted as good and honest practice in the opensource community. It's mind boggling how many times I see programs using opensource components, and there's no mention of such anywhere in the program docs. Open source is free as in free to use, not free as in free to steal and make your own. Too many commercial entities forget this point, and just rip off opensource to line their own pockets, and that's really a shame. --- 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.
Re: [Audyssey] Game Engines was Heli
I aggree with you. I enjoy crediting software I use especially other free, comercial or opensource software, Something like I used such and such at such a link. This software is quite good and I like it. I may even put a small warenty statement maybe a trademark or something, maybe the licence version used for that software, ie gpl 2.1 and its copywrite and trademark. At most that is. Now over that I couldn't be bothered. Ofcause I could just include the product licencing with the product. Most os stuff i have used have included the licence for the code they are using it on as well as their own licence in seperate files and if its that way I don't mind having another seperate file with all the stuff in it. However coppying it all into manuals is not what I care for However if I have to put a note about aggreeing to stuff in coppying.txt or something or to read it I can handle that. And ofcause as long as i used the same thing I could just shove all the licences into one file, and as long as I kept those I could be cool THe issue would be if I had to change libs or something like that. At 07:00 a.m. 27/01/2011, you wrote: Hi Travis, Here are my two cents on this. I certainly agree that one should give credit where credit is due, but what I don't agree with as a whole on the open source market is how a lot of libraries force you to put in a lot of legal mumbo jumbo in your documentation rather than just an acknowledgement and a link to their website etc. The lgpl is a great example, there you have to include a long section on how they don't accept warranty etc. On top of this, since I am making an engine, the use of many libraries would force my end users to include the same legal garbage in the game that they make with my engine. I'm not having that, so I have intentionally chosen libraries that don't require you to put credits in the documentation which means that I am free to lay them out in a way that suits the format of my application and also to not force my users to include anything to do with my internal libraries in their game manuals. The bottom line is, I don't mind giving credit but I won't use libraries that strictly enforce this. Kind regards, Philip Bennefall - Original Message - From: Travis Siegel tsie...@lothlorien.nfbcal.org To: gamers@audyssey.org Sent: Wednesday, January 26, 2011 9:39 AM Subject: Re: [Audyssey] Game Engines was Heli Except that opensource software is supposed to be recognized as such by folks who use it. Too often, I've found programs that use opensource software, then ignore the license requirements which state that they should, can, or must mention in their docs that they are using said piece of software in their programs. I've also seen blatent commercial rip-offs of opensource products that are obviously nothing more than the opensource program repackaged, and distributed as their own product, when this is clearly not the case. That kind of exploitation is illegal, but bringing anyone to task for such things is rough, and expensive, and usually doesn't happen, and the exploiters know this, which is why they do it. For example, nvda is free and opensource, I saw a company (3 or 4 years ago) selling a screen reader of their own, which was clearly nvda, but they had renamed it, and charged $250 for it. That is the kind of thing that is not allowed with opensource products. Most opensource products (especially libraries) request that you mention them in your program documentation, but some of them don't require this, simply ask that it be done, but don't demand it. My own opinion, is that if someone is using a product, especially if it was something they're using for profit, the least they can do is acknowledge where said shortcuts came from, which is generally accepted as good and honest practice in the opensource community. It's mind boggling how many times I see programs using opensource components, and there's no mention of such anywhere in the program docs. Open source is free as in free to use, not free as in free to steal and make your own. Too many commercial entities forget this point, and just rip off opensource to line their own pockets, and that's really a shame. --- 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
Re: [Audyssey] Game Engines was Heli
Hi Thomas, I certainly don't think that your engine is not marketable just because BGT is around. I'm sure you do things totally differently as compared to myself and BGT, and so your engine might appeal to some where BGT has not done so and the other way around. I would definitely say that you should give it a try, and ignore BGT's presence in that sense. Besides, if we do end up competing, that's a good thing in itself. Competition provides insentive for both of us to make our engines the very best they can be, and then let the end user decide. Kind regards, Philip Bennefall - Original Message - From: Thomas Ward thomasward1...@gmail.com To: phi...@blastbay.com; Gamers Discussion list gamers@audyssey.org Sent: Monday, January 24, 2011 4:56 AM Subject: Re: [Audyssey] Game Engines was Heli Hi Philip, Philip wrote: I'm neither for or against open source software. I am very thankful to those who write open source libraries and allow them to be used in commercial applications, as that speeds up my own development by about 500 %. But I would never make any of my games open source because of the simple fact that I don't want people to mess around with or steal my source code. I have spent a considerable sum of money outsourcing a lot of the core parts of my game engine and so it would be utter foolishness for me to simply throw that money in the sea as we say in Sweden. It is for the same reason that I protect my sounds from being altered or stolen, because I don't want the investments I have made in that department to simply be exploited. I'm happy to provide my game engine along with some open source components to do trivial things such as my menu class, my sound pool class to handle audio environments, my number speaker class to intelligently concatenate sound files to have numbers spoken, etc etc. But the real code is protected and always will be. My reply: I know exactly how you feel. I just spent the last two/three years writing the Genesis 3D Engine in order to produce games like Mysteries of the Ancients, Raceway, etc and now that it is ready for production I hate the thought of just handing the source code over to anyone who wants it. Oh, I've considered a time or two of releasing an open source version, but in the end my rationality is the same is yours. I spent both time and money working on this engine and I don't want my work to be taken and used without any kind of financial compensation. With a GPL license someone could take my engine, modify it, keep it open source, and make money off of creating games with it without paying me royalties etc. I think after a lot of time, money, and work involved I should get a little money off of my engine. Although, with BGT sales I don't think there is much of a market for G3D now anyway. Cheers! --- 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.
Re: [Audyssey] Game Engines was Heli
Hi Thomas and others, Just a few points from a probably biased user :-) I think the idea of Open Source Software are generally miss understood. Part of that may be because of the fact that certain groups prefer to call it Free Software, which is associated with freeware. Open source software is not freeware and will never be. The idea of Open Source Software is just that the source code should be open and available to any one who would like to study or modify it. That is also the reason that many people including myself prefer to use Linux. If I want my computer to say hello every time it begins the boot process, I can do so without having to edit some binary file with a hex editor. Also it encourage the studying of source code. Thus if someone enters the audio gaming community, he/she can immediately find out how a game engine works for instance without having to reinvent the wheel. Some people think that open source software grows faster than other software, but that is mostly open for debate. Nothing prevents one from selling a program under the GPL, although your users must receive the same rights under the GPL, and can for instance sell it themselves, modify it or just give it away. One thing I've thought about is to put the game itself under an open source license, and sell the sounds and/or music. Take care, Rynhardt * Thomas Ward thomasward1...@gmail.com [110123 04:53]: Hi Philip, That is very good to know. As I mentioned in my earlier message to the list I'm currently looking at replacing one of my computers with a Mac. Recently my old desktop, we used as a family computer, gave up the ghost over the Christmas holidays. Now, my wife and I are in the process of discussing replacing it. If we do decide to replace it with a Mac I'll be interested in porting my current projects, including the Genesis 3D Engine, to Mac OS. If you happen to release a copy of BGT for Mac before I get there I'd probably consider buying a license for the port. However, that said the APIs for Linux and the APIs for Mac OS are not that different. For example, I have a rough idea of how I'm going to create the Mac OS and Linux version of the Genesis Engine. I'll begin with writing a middleware library similar to Streemway that wraps OpenAL and loads wav, ogg, and other open source file types and mixes them with OpenAL. For things like threading, serialization, etc I'll use the cross-platform boost library. Finally, input, networking, and the window manager will be handled by SDL 1.2. I believe that this would provide an excellent basis for any game engine targeting the Mac or Linux operating systems. Although, there is an alternative way of handling this. SFML already has a decent networking API, supports OpenAL via sfml-audio, input handling is fine, threading works pretty good on Linux, and the only complaint I have is the window manager. It works fine on Linux, I hear it works fine on Mac, but crashes the OS on Windows. So SFML sounds like the best solution for a Mac specific engine, but I wouldn't consider SFML for a Windows engine based on its buggy window manager. Still I agree with you that at this point Mac is a developers second choice in terms of operating system to support. While Linux is fine as an operating system most of the Linux users I know left Linux in favor of the Mac. Plus because Mac OS is a commercial operating system the majority of the people using it are willing to pay money for commercial software. All too many Linux users I know are hung up on the free and open source view and absolutely refuse to pay for commercial software in any way, shape, or form. They expect software for Linux to remain free, open source, and without commercial licensing. That is unrealistic considering the fact I have to license music, sounds, and so on that costs me hundreds of dollars per game. The Marxist view that all software should be free, shared, community property is fine to a certain point, but doesn't work if we are dealing with capitalist companies out to make a buck for everything. Therefore since we live in a capitalist society I have to run my software company that way to make a buck myself to continue producing said products. In short, I agree with you. Mac is probably my next choice as well. It has nothing to do with weather I like Linux or not. I've just concluded the money isn't really in it. Between the fact there are less users their and the fact too many are hung up on Marxist idiology it will be very hard to market a commercial product there. If I can produce Linux versions inexpensively and make a few extra on it fine, but Mac and Windows seam to me to be the most financially viable markets long term. HTH On 1/22/11, Philip Bennefall phi...@blastbay.com wrote: Hi Thomas, Just to enter in this discussion a little. I am actually considering buying a Mac when I have enough money saved up. I'm not very
Re: [Audyssey] Game Engines was Heli
Hi Thomas and Rhynhardt, I'm neither for or against open source software. I am very thankful to those who write open source libraries and allow them to be used in commercial applications, as that speeds up my own development by about 500 %. But I would never make any of my games open source because of the simple fact that I don't want people to mess around with or steal my source code. I have spent a considerable sum of money outsourcing a lot of the core parts of my game engine and so it would be utter foolishness for me to simply throw that money in the sea as we say in Sweden. It is for the same reason that I protect my sounds from being altered or stolen, because I don't want the investments I have made in that department to simply be exploited. I'm happy to provide my game engine along with some open source components to do trivial things such as my menu class, my sound pool class to handle audio environments, my number speaker class to intelligently concatenate sound files to have numbers spoken, etc etc. But the real code is protected and always will be. For my Mac port when the time comes, I will probably be using CoreAudio directly. For networking I can stick with what I already have, since ENet fits the bill for BGT perfectly and already works on Mac OS as far as I'm aware. The same goes for AngelScript. Kind regards, Philip Bennefall - Original Message - From: Rynhardt Kruger rynkru...@gmail.com To: Gamers Discussion list gamers@audyssey.org Sent: Sunday, January 23, 2011 2:50 PM Subject: Re: [Audyssey] Game Engines was Heli Hi Thomas and others, Just a few points from a probably biased user :-) I think the idea of Open Source Software are generally miss understood. Part of that may be because of the fact that certain groups prefer to call it Free Software, which is associated with freeware. Open source software is not freeware and will never be. The idea of Open Source Software is just that the source code should be open and available to any one who would like to study or modify it. That is also the reason that many people including myself prefer to use Linux. If I want my computer to say hello every time it begins the boot process, I can do so without having to edit some binary file with a hex editor. Also it encourage the studying of source code. Thus if someone enters the audio gaming community, he/she can immediately find out how a game engine works for instance without having to reinvent the wheel. Some people think that open source software grows faster than other software, but that is mostly open for debate. Nothing prevents one from selling a program under the GPL, although your users must receive the same rights under the GPL, and can for instance sell it themselves, modify it or just give it away. One thing I've thought about is to put the game itself under an open source license, and sell the sounds and/or music. Take care, Rynhardt * Thomas Ward thomasward1...@gmail.com [110123 04:53]: Hi Philip, That is very good to know. As I mentioned in my earlier message to the list I'm currently looking at replacing one of my computers with a Mac. Recently my old desktop, we used as a family computer, gave up the ghost over the Christmas holidays. Now, my wife and I are in the process of discussing replacing it. If we do decide to replace it with a Mac I'll be interested in porting my current projects, including the Genesis 3D Engine, to Mac OS. If you happen to release a copy of BGT for Mac before I get there I'd probably consider buying a license for the port. However, that said the APIs for Linux and the APIs for Mac OS are not that different. For example, I have a rough idea of how I'm going to create the Mac OS and Linux version of the Genesis Engine. I'll begin with writing a middleware library similar to Streemway that wraps OpenAL and loads wav, ogg, and other open source file types and mixes them with OpenAL. For things like threading, serialization, etc I'll use the cross-platform boost library. Finally, input, networking, and the window manager will be handled by SDL 1.2. I believe that this would provide an excellent basis for any game engine targeting the Mac or Linux operating systems. Although, there is an alternative way of handling this. SFML already has a decent networking API, supports OpenAL via sfml-audio, input handling is fine, threading works pretty good on Linux, and the only complaint I have is the window manager. It works fine on Linux, I hear it works fine on Mac, but crashes the OS on Windows. So SFML sounds like the best solution for a Mac specific engine, but I wouldn't consider SFML for a Windows engine based on its buggy window manager. Still I agree with you that at this point Mac is a developers second choice in terms of operating system to support. While Linux is fine as an operating system most of the Linux users I know left Linux in favor of the Mac. Plus because Mac OS is a commercial operating
Re: [Audyssey] Game Engines was Heli
Hi Philip, ... But I would never make any of my games open source because of the simple fact that I don't want people to mess around with or steal my source code. ... snip Indeed that is your choice. Actually by using angelscript in BGT you make it available to a wide audience for testing and thus contributing indirectly to it's development. I hope I didn't came across as advocating in my original message. I was just stating the other side of the argument. Maybe I was advocating a bit, but that's my choice as well. smile Take care, Rynhardt * Philip Bennefall phi...@blastbay.com [110123 16:13]: Hi Thomas and Rhynhardt, I'm neither for or against open source software. I am very thankful to those who write open source libraries and allow them to be used in commercial applications, as that speeds up my own development by about 500 %. But I would never make any of my games open source because of the simple fact that I don't want people to mess around with or steal my source code. I have spent a considerable sum of money outsourcing a lot of the core parts of my game engine and so it would be utter foolishness for me to simply throw that money in the sea as we say in Sweden. It is for the same reason that I protect my sounds from being altered or stolen, because I don't want the investments I have made in that department to simply be exploited. I'm happy to provide my game engine along with some open source components to do trivial things such as my menu class, my sound pool class to handle audio environments, my number speaker class to intelligently concatenate sound files to have numbers spoken, etc etc. But the real code is protected and always will be. For my Mac port when the time comes, I will probably be using CoreAudio directly. For networking I can stick with what I already have, since ENet fits the bill for BGT perfectly and already works on Mac OS as far as I'm aware. The same goes for AngelScript. Kind regards, Philip Bennefall - Original Message - From: Rynhardt Kruger rynkru...@gmail.com To: Gamers Discussion list gamers@audyssey.org Sent: Sunday, January 23, 2011 2:50 PM Subject: Re: [Audyssey] Game Engines was Heli Hi Thomas and others, Just a few points from a probably biased user :-) I think the idea of Open Source Software are generally miss understood. Part of that may be because of the fact that certain groups prefer to call it Free Software, which is associated with freeware. Open source software is not freeware and will never be. The idea of Open Source Software is just that the source code should be open and available to any one who would like to study or modify it. That is also the reason that many people including myself prefer to use Linux. If I want my computer to say hello every time it begins the boot process, I can do so without having to edit some binary file with a hex editor. Also it encourage the studying of source code. Thus if someone enters the audio gaming community, he/she can immediately find out how a game engine works for instance without having to reinvent the wheel. Some people think that open source software grows faster than other software, but that is mostly open for debate. Nothing prevents one from selling a program under the GPL, although your users must receive the same rights under the GPL, and can for instance sell it themselves, modify it or just give it away. One thing I've thought about is to put the game itself under an open source license, and sell the sounds and/or music. Take care, Rynhardt * Thomas Ward thomasward1...@gmail.com [110123 04:53]: Hi Philip, That is very good to know. As I mentioned in my earlier message to the list I'm currently looking at replacing one of my computers with a Mac. Recently my old desktop, we used as a family computer, gave up the ghost over the Christmas holidays. Now, my wife and I are in the process of discussing replacing it. If we do decide to replace it with a Mac I'll be interested in porting my current projects, including the Genesis 3D Engine, to Mac OS. If you happen to release a copy of BGT for Mac before I get there I'd probably consider buying a license for the port. However, that said the APIs for Linux and the APIs for Mac OS are not that different. For example, I have a rough idea of how I'm going to create the Mac OS and Linux version of the Genesis Engine. I'll begin with writing a middleware library similar to Streemway that wraps OpenAL and loads wav, ogg, and other open source file types and mixes them with OpenAL. For things like threading, serialization, etc I'll use the cross-platform boost library. Finally, input, networking, and the window manager will be handled by SDL 1.2. I believe that this would provide an excellent basis for any game engine targeting the Mac or Linux operating systems. Although, there is an alternative way of handling this. SFML already has
Re: [Audyssey] Game Engines was Heli
Hi Rynhardt, Oh I think I expressed myself carelessly. I have sent off a lot of bug reports to Andreas, the creator of AngelScript, and so I have definitely done what I can to make the library more stable by testing it myself as well as letting all my users test it of course. This benefits both myself, my customers, Andreas and all his other AngelScript users, and is a splended thing. What I was trying to say was that I would not myself want to lead an open source project of the same scale as I can see no way to justify the time and money that would have to go into it. Kind regards, Philip Bennefall - Original Message - From: Rynhardt Kruger rynkru...@gmail.com To: phi...@blastbay.com; Gamers Discussion list gamers@audyssey.org Sent: Sunday, January 23, 2011 3:48 PM Subject: Re: [Audyssey] Game Engines was Heli Hi Philip, ... But I would never make any of my games open source because of the simple fact that I don't want people to mess around with or steal my source code. ... snip Indeed that is your choice. Actually by using angelscript in BGT you make it available to a wide audience for testing and thus contributing indirectly to it's development. I hope I didn't came across as advocating in my original message. I was just stating the other side of the argument. Maybe I was advocating a bit, but that's my choice as well. smile Take care, Rynhardt * Philip Bennefall phi...@blastbay.com [110123 16:13]: Hi Thomas and Rhynhardt, I'm neither for or against open source software. I am very thankful to those who write open source libraries and allow them to be used in commercial applications, as that speeds up my own development by about 500 %. But I would never make any of my games open source because of the simple fact that I don't want people to mess around with or steal my source code. I have spent a considerable sum of money outsourcing a lot of the core parts of my game engine and so it would be utter foolishness for me to simply throw that money in the sea as we say in Sweden. It is for the same reason that I protect my sounds from being altered or stolen, because I don't want the investments I have made in that department to simply be exploited. I'm happy to provide my game engine along with some open source components to do trivial things such as my menu class, my sound pool class to handle audio environments, my number speaker class to intelligently concatenate sound files to have numbers spoken, etc etc. But the real code is protected and always will be. For my Mac port when the time comes, I will probably be using CoreAudio directly. For networking I can stick with what I already have, since ENet fits the bill for BGT perfectly and already works on Mac OS as far as I'm aware. The same goes for AngelScript. Kind regards, Philip Bennefall - Original Message - From: Rynhardt Kruger rynkru...@gmail.com To: Gamers Discussion list gamers@audyssey.org Sent: Sunday, January 23, 2011 2:50 PM Subject: Re: [Audyssey] Game Engines was Heli Hi Thomas and others, Just a few points from a probably biased user :-) I think the idea of Open Source Software are generally miss understood. Part of that may be because of the fact that certain groups prefer to call it Free Software, which is associated with freeware. Open source software is not freeware and will never be. The idea of Open Source Software is just that the source code should be open and available to any one who would like to study or modify it. That is also the reason that many people including myself prefer to use Linux. If I want my computer to say hello every time it begins the boot process, I can do so without having to edit some binary file with a hex editor. Also it encourage the studying of source code. Thus if someone enters the audio gaming community, he/she can immediately find out how a game engine works for instance without having to reinvent the wheel. Some people think that open source software grows faster than other software, but that is mostly open for debate. Nothing prevents one from selling a program under the GPL, although your users must receive the same rights under the GPL, and can for instance sell it themselves, modify it or just give it away. One thing I've thought about is to put the game itself under an open source license, and sell the sounds and/or music. Take care, Rynhardt * Thomas Ward thomasward1...@gmail.com [110123 04:53]: Hi Philip, That is very good to know. As I mentioned in my earlier message to the list I'm currently looking at replacing one of my computers with a Mac. Recently my old desktop, we used as a family computer, gave up the ghost over the Christmas holidays. Now, my wife and I are in the process of discussing replacing it. If we do decide to replace it with a Mac I'll be interested in porting my current projects, including the Genesis 3D Engine, to Mac OS. If you happen to release a copy of BGT for Mac before I get there I'd probably consider buying
Re: [Audyssey] Game Engines was Heli
Hi Rynhardt, Rinhardt wrote: I think the idea of Open Source Software is generally miss understood. Part of that may be because of the fact that certain groups prefer to call it Free Software, which is associated with freeware. My response: Agreed. I use Linux myself, have done so for a long time, but unlike a lot of people I've actually read the various license agreements. I pretty much understand where the General Public License stands on various issues, but I don't think your average Joe and Jane does. It is just legal mumbo jumbo to them. They prefer to think of Linux as a free OS when there certainly are commercial distros like Mandriva, Suse, Red Hat, etc that make money off of selling the books, cds, and technical support. It is just that the sourse code is available on demand if you want it. Unfortunately, based on my discussions with several Linux users on various mailing list they are under some illusion that Linux is free and therefore all software for it should be free too. Rynhardt wrote: Open source software is not freeware and will never be. The idea of Open Source Software is just that the source code should be open and available to any one who would like to study or modify it. That is also the reason that many people including myself prefer to use Linux. If I want my computer to say hello every time it begins the boot process, I can do so without having to edit some binary file with a hex editor. Also it encourage the studying of source code. Thus if someone enters the audio gaming community, he/she can immediately find out how a game engine works for instance without having to reinvent the wheel. My reply: Yes, that's exactly what interested me about Linux as well. If there is something I wanted to modify I could make a change in the source, recompile it with gcc, and happily go on my way with my custom program/OS. Admitedly though, this advantage of having the source is really only useful if you are a programmer with the skills to modify'/study it in the first place. For the average Joe/Jane Linux software is often viewed as freeware, and insist that products for Linux remain freeware etc even though that isn't the intent of the GPL. Rynhardt wrote: One thing I've thought about is to put the game itself under an open source license, and sell the sounds and/or music. My reply: That works. I've seen a few games do that. For example, after Loki Games bit the dust ID Software decided to make Quake I open source, putting the source code in the public domain, but the sounds, music, and graphics were under a separate license. There is a lot of advantages to doing this. One, you are still offering the software itself under a open source license allowing potential game developers to use your engine, code, etc for future projects. Second, since the multimedia is under a separate license you can sell the game giving the software away for free but make your money off of the graphics, sounds, and music. The multimedia would be held under standard copyrights while the software is public domain. It is an interesting way of bridging the gap between open source and commercial software. Unfortunately, if there is any kind of product key system etc that can't be released as open source otherwise it would compromise licensing the software. Cheers! --- 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.
[Audyssey] Game Engines was Heli
Hi Philip, That is very good to know. As I mentioned in my earlier message to the list I'm currently looking at replacing one of my computers with a Mac. Recently my old desktop, we used as a family computer, gave up the ghost over the Christmas holidays. Now, my wife and I are in the process of discussing replacing it. If we do decide to replace it with a Mac I'll be interested in porting my current projects, including the Genesis 3D Engine, to Mac OS. If you happen to release a copy of BGT for Mac before I get there I'd probably consider buying a license for the port. However, that said the APIs for Linux and the APIs for Mac OS are not that different. For example, I have a rough idea of how I'm going to create the Mac OS and Linux version of the Genesis Engine. I'll begin with writing a middleware library similar to Streemway that wraps OpenAL and loads wav, ogg, and other open source file types and mixes them with OpenAL. For things like threading, serialization, etc I'll use the cross-platform boost library. Finally, input, networking, and the window manager will be handled by SDL 1.2. I believe that this would provide an excellent basis for any game engine targeting the Mac or Linux operating systems. Although, there is an alternative way of handling this. SFML already has a decent networking API, supports OpenAL via sfml-audio, input handling is fine, threading works pretty good on Linux, and the only complaint I have is the window manager. It works fine on Linux, I hear it works fine on Mac, but crashes the OS on Windows. So SFML sounds like the best solution for a Mac specific engine, but I wouldn't consider SFML for a Windows engine based on its buggy window manager. Still I agree with you that at this point Mac is a developers second choice in terms of operating system to support. While Linux is fine as an operating system most of the Linux users I know left Linux in favor of the Mac. Plus because Mac OS is a commercial operating system the majority of the people using it are willing to pay money for commercial software. All too many Linux users I know are hung up on the free and open source view and absolutely refuse to pay for commercial software in any way, shape, or form. They expect software for Linux to remain free, open source, and without commercial licensing. That is unrealistic considering the fact I have to license music, sounds, and so on that costs me hundreds of dollars per game. The Marxist view that all software should be free, shared, community property is fine to a certain point, but doesn't work if we are dealing with capitalist companies out to make a buck for everything. Therefore since we live in a capitalist society I have to run my software company that way to make a buck myself to continue producing said products. In short, I agree with you. Mac is probably my next choice as well. It has nothing to do with weather I like Linux or not. I've just concluded the money isn't really in it. Between the fact there are less users their and the fact too many are hung up on Marxist idiology it will be very hard to market a commercial product there. If I can produce Linux versions inexpensively and make a few extra on it fine, but Mac and Windows seam to me to be the most financially viable markets long term. HTH On 1/22/11, Philip Bennefall phi...@blastbay.com wrote: Hi Thomas, Just to enter in this discussion a little. I am actually considering buying a Mac when I have enough money saved up. I'm not very interested in Linux, so I believe that when I do eventually begin the work of porting BGT to another platform it'll be on Mac to start with. Kind regards, Philip Bennefall --- 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.
