Hello everyone, I guess this survey would mainly be for those game developers who would like a say in the end product , but if this subject is of interest to you as an end user please by all means let's have your thoughts too.
Over the past month or so I am slowly getting back into software and game development, and of course one project I am strongly looking at is the USA Games Evolution Engine. At the current moment the Evolution Engine is written in C++ and can be compiled as a dynamic library or can be statically linked into a project as it currently is in Mysteries of the Ancients, Raceway, and other games in development. However, as I mainly wrote this for myself it is okay as is, but at the same time I am consciously aware it isn't in a newbie friendly form that can be taken up and used by just anyone which is the reason for this survey. One of the principle strengths of Philip Bennefall's BGT Toolkit it is written in C++, but all the functions are exposed through a nice and easy to use scripting language called Angelscript. The strength of this approach is simply that a new game developer can just take up the BGT programming guide and start writing a game without knowing how SAPI works, how DirectX works, etc and all of the basic functionality is right there to use without the overhead of languages like C or C++. On the down side with BGT if a new game developer uses Angelscript they aren't actually learning a full blown programming language, only the scripting capabilities of BGT, and if they want to write something else other than a game they still have to go out and learn another language. In other words BGT is designed for one purpose, and isn't flexible enough to design other programs and applications out side of games. Plus if the end user is a Mac user or a Linux user BGT currently isn't an option anyway. My approach falls somewhere between those two extremes, and is in my opinion a better solution for all of the above except for the fact it wasn't designed for newbies in mind which brings us to the point of this survey. I've been thinking for quite some time what I should do is rewrite the Evolution Engine to be more newbie friendly as well as have some cross-platform implementation in mind. Then, I could license it to third-party game developers who want to just plug it into a game project and get everything up and running with a minimum amount of code and difficulty as possible. There are two ways in which I could do this. The first is I could rewrite the Evolution Engine in .NET like the original version, but only using the latest versions of the .NET Framework, SlimDX, and so forth. There are a number of advantages to doing it this way. One of the most important advantages is by creating a .NET library someone using Visual C++ .NET, Visual C# .NET, or Visual Basic .NET could simply incorporate my engine into their game project and have a choice in what language they wish to use when doing so. If a developer likes C# .NET they could use that, and if they prefer VB .NET they could use that instead. The choice is really up to them. You don't get that kind of choice with BGT which is one of the big advantages I see in basing it on .NET. Another advantage is thanks to the Mono Runtime C# .NET and Visual Basic .NET code can be quite portable and cross-platform. If written to be cross-platform using SDL .NET, for example, game developers can write games for Mac and Linux even if they do not own or use that specific platform. All they need to know is what to do in order to make their game cross-platform. So once again another advantage for this method of rewriting the Evolution Engine in .NET. Next, obviously languages like C# .NET and Visual Basic .NET are full blown programming languages, but are no where as difficult as C or C++. The advantage of my Evolution .NET library is while you may primarily rely on it for game development the stuff you learn in .NET can be used in other types of projects too which means you are learning to write more than just games which can come in handy. Finally, as Windows Vista, Windows 7, and Windows 8 already come with the .NET Framework and it can be updated through Windows Update its no where near as much of a problem as it was a few years ago when it was new. You can be assured that anyone who has purchased a new system with one of those operating systems can run your game without much problem and should have the basic requirements installed. All they may need to do is install any extra runtime requirements like SlimDX or SDL .NET which do not come with Windows by default, but the .NET Framework itself should be installed and ready to go, and is the preferred development platform of many software developers today anyway. With all those good things in mind I'm obviously personally in favor of this project. However, it is not perfect and comes with a few down sides I should mention up front. First, while .NET games can be cross-platform via Mono Mac OS has a problem with .NET applications. One problem is that program executables can't be simply clicked on and launched as is the case on Linux and Windows. Instead someone must actually open a terminal and do "mono program.exe" to launch the program. This is a bit of an annoyance for Mac users as they can't just click on program.exe to launch it, but it should work fine once invoked from the command line. The other issue is that .NET forms are accessible on Windows and Linux VoiceOver still is unable to read applications written with .NET forms. So its not the ideal choice for Mac game development obviously, but is easier than doing it in say C++. Second, depending on how many third-party APIs you use in your game there may be a lot of extra Runtime packages your end users may need to install.This remains to be the bane of game development as things like SlimDX, for instance, don't come with Windows and therefore needs to be shipped with your game or installed prior to downloading and running your game. Some people may or may not have a problem with this, but it is a good thing to keep in mind. Finally, .NET applications are easy to crack if a developer is not careful. If security is a serious issue then you will need to purchase a third-party .NET obfuscation tool to scramble your .NET code to keep crackers from disassembling your game, changing your licensing info, etc and then recompiling it and releasing it on the web for any two-bit pirate to play. This is by far the most troubling issue a commercial .NET developer has to face. There is however another option I have been considering, but am uncertain if it is really better than the .NET version of the engine above. The idea would involve rewriting the Evolution engine in Python, and releasing it as a third-party module or API for the Python interpreter. It has both its pros and its cons too. To begin with it would obviously be cross-platform as Python works equally well on Mac, Linux, and Windows if designed that way which I would certainly do. Python is generally considered easy to learn, easy to use, and is a very newbie friendly programming language. All good reasons to target this language with the Evolution Engine. However, it has its cons which are problematic. The most irritating issue is version conflicts. If you were to compile your Python program as *..pyc files and redistribute them to others they would have to be running the exact same version of the Python interpreter you are running else it won't work. If you happen to compile your game with Python 2.7.5 and your end user is running 2.7.3 it will bomb out. Therefore you really have to build a platform specific executable that will work, but puts you in the position of building executable versions for every platform you intend to support and target. Not something I find particularly ideal if cross-platform development is your aim. The other issue here is that Python was designed primarily for open source development. It lacks real security for commercial developers. It is a piece of cake to decompile a *.pyc file and get back the Python code it was written in. Were .NET does have obfuscation tools I am unaware of a similar tool for Python to secure your code from theft and piracy. So from a security standpoint it isn't a good choice. However if you aren't thinking of a commercial product then none of this really matters a whole lot. The last choice is to simply compile and sell my C++ version of the Engine library as is. Obviously it offers many things BGT does, but in order to use it you either have to already know C++ or learn C++ to use it. As I am uncertain if people really want to do that I am offering up the other options above to make it more newbie friendly. So now that I have given you the options would you rather I rewrite the engine for .NET, make a Python version, or sell the C++ version as is? --- Gamers mailing list __ [email protected] If you want to leave the list, send E-mail to [email protected]. 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/[email protected]. If you have any questions or concerns regarding the management of the list, please send E-mail to [email protected].
