Hi all, A discussion came up on the USA Games Gamers list I thought should be copied here so that those of you who have the same thoughts, concerns, and questions as Claudio could read my responses to his message. Below is a transcript of my conversation for your reading pleasure.
Well, Claudio, for what it is worth I do completely understand where you are coming from and why you feel the way you do. However, I must say that some of your opinions below are based on inaccurate information, and I'd like to take this time to sort of set the record straight if I may. To begin with I know a lot of your opinions were based on statements and things I had said in some USA Games news letters. The problem is while I did not intend to mislead anyone the reality is that in a lot of those news letters I often would write about things I was considering doing, write about things I wanted to do, but never actually got around to doing due to time and circumstance. Meaning that there is a difference between reality and what I said I was going to do, and that is why I feel it important you here the other side of this before making statements that are based on inaccurate information. Quote you're absolutely responsible for the long delay of those two games. End quote I do agree with you that it is my fault and it was my responsibility to get those games released as soon as possible, but there are some extenuating circumstances which I think warranted the long delays which I will explain later on in this message. Quote I am not an expert in project management at all, but I do understand that taking over such a project like you did needs to be planned before it can be done. End quote As a matter of fact I did have a plan when starting out with those projects. When I initially took control of Montezuma's Revenge and Raceway I had planned on writing them in Microsoft's C# .NET, using Managed DirectX, for the Windows platform. At the time I was intending to support Windows XP and later versions of Windows. However, about a year after I had started working on those projects Microsoft announced that they were not going to release any updates to Managed DirectX, Microsoft's DirectX technology for .NET, and in 2008 they abandoned it completely. They instead released a new API called XNA Framework which is largely inaccessible to a blind user. It is for this reason I had to drop C# .NET for game development and look for an alternative to continue those projects. I had no idea at the time that Microsoft would do that to me, and while I could have avoided that situation if I had chosen a different language, APIs, etc the fact is what happened to me was largely out of my control unless I wanted to forge ahead knowing the technologies I was using were no longer viable long term. Quote And because you didn't have such a plan, people could read newsletter after newsletter, where you reported the development of the game on cross platform, then a switch back to windows, after that a new attempt on Mac and so on. End quote Well, if you consider the fact the games absolutely had to be rewritten anyway after Microsoft discontinued Managed DirectX I wanted to look into other possibilities before forging ahead with writing said games. At the time there were people beginning to look at Mac with VoiceOver and I was already beginning to use Linux for a lot of stuff so it only made sense to me, at least, to look at if it was possible to write the games in such a way that I could support Windows, Mac, and Linux too. I freely admit I probably spent more time than I should have on that endeavor, but its a case of live and learn. I did learn a lot from that time spent looking into other platforms, languages, APIs, etc and am more prepared now to develop a better product than I was then. Quote If you had fixed from the beginning just the programming language and the desired platforms, I am pretty sure we would have two finished games today. End quote This is inarguably true, but what you don't understand is if I had done that Montezuma's Revenge and Raceway would now be experiencing the same problems that STFC has. Namely that end users would have to install several .NET components like the .NET Framework, Managed DirectX, etc which uses a lot of hard drive space, and Managed DirectX has a few nasty bugs that will not be fixed. More importantly since I was developing those games using the express version of C# .NET I could not compile the games for 64-bit Windows platforms, meaning that if I had continued using the languages and tools I was using in 2006 <Montezuma's Revenge, Raceway, and Final Conflict would not now run on 64-bit versions of Vista, Windows 7, and Windows 8. People would have purchased games that will not run on new versions of Windows. So you should be thankful I stopped doing what I was doing and have since chosen languages and tools more suited to new versions of Windows. So the games might have been done sooner, but not done right. I guess which is more important done right or done sooner? Quote But instead, you just spend month after month with changing programming technologies and platforms. End quote That's a bit of an over exaggeration of the facts, and it is one of those cases where I talked about my thoughts in various news letters but did not actually do in fact. I certainly did some experimentation and testing with other languages such as Java before deciding on C++, but as for the games themselves they only have been written in two different languages. When I got the games from James North I began writing them in C# .NET, when I figured out that was not going to work, I began rewriting them in C++ at the end of 2009. So its not a case of writing them, rewriting them and rewriting them again the way you are implying. I don't think writing test applications that took a week or so to build to test out an API or a programming language really counts as months and months of wasted time or effort. As for switching platforms that is partly true. However, it is not in any way the big deal you are making it out to be. Keep in mind here that the games themselves, Mysteries of the Ancients and Raceway, are written using my game engine which is a high level wrapper for various APIs etc on the host platform. Therefore in order to switch to a different platform, say Windows to Linux, all I need do is write a few extra API wrappers for Linux and recompile the games. Perhaps a week at most. Not months and months of work. So lets be realistic here when placing blame for delays that this or that decision may have caused. Quote All the customers paid for a product on windows, so it's no question that you also have to see that your version of the game works on Windows. End quote I don't believe I ever said I was not going to release a version for Windows. As a matter of fact I have always intended from the beginning to release a version for Windows, and I would not do that to people who paid money for a product from me. Not doing so would be morally reprehensible. So while I may consider creating Mac and Linux versions at some point I definitely would be releasing a version compatible for Windows if for no other reason than that is what they paid for. So don't worry about me not offering a Windows version, because I have every intention of doing so. Quote And - how many people are using another operating system than Windows? End quote that's an interesting question. The best answer is probably more than you think. I know that the Mac Visionaries list has quite a few Mac users on there, and there are quite a number of blind users in low income situations now using Linux with the Orca screen reader. I don't have any hard figures off the top of my head, but what you are implying is those markets do not count which is not really true any more. Take, for example, the use of iOS. Right now iOS 7 has a huge following of blind users with iPods, iPads, and iPhones which is equal to that if not more so than Windows right now. I have to consider that a valid market even if you personally don't. Quote Not many, and those who do have most also access to a windows machine, so developing an audio game for another platform than windows is nothing more than a waste of time. End quote That's a subjective opinion on your part, and one I strongly disagree with. Even if money was not an issue here there are all kinds of issues you are over looking. For one I use Linux myself so for me being able to play my games on Linux would not be a waste of time. There are hundreds of blind Mac users out there now, and I am sure they'd appreciate being able to play the game on their Mac rather than having to boot into a Windows VM. So just because you are not a Mac or Linux user yourself don't think everyone feels supporting those platforms is an utter waste of time because it is not. Plus as I mentioned before iOS is becoming very popular. Games for iPhone etc are exploding onto the audio games market, and even if I sold the games for $5 each to 1,000 VI customers that is $5,000 USD. That is certainly not a waste of time. I consider that a decent amount of extra spending cash. Quote VB6 might be an old technology, but I have to remind you that there are people who are playing Jim Kitchens games on their Windows 8 machine. End quote Yes, I am aware of that, but there are plenty of technical issues with Visual Basic 6 that you are obviously unaware of. Besides that just because Jim Kitchen or another developer still uses the language and it happens to work on Windows 8 does not mean it is the right technology for the job. I'm not sure what to say here without being offensive to anyone, but I think you will just have to trust me when I say it was not appropriate for my game engine which all of the games were developed with. there are problems with VVB 6 that make it an undesirable option for me. Quote Even if Microsoft drops the support of VB6, that's no problem at all because all the libraries needed to use VB6 programs can be easily installed and configured. End quote No, that is where you are wrong. Yes, it is possible to make VB 6 games and programs run on newer operating systems like Windows 8, but there are a lot of issues you either don't know about or don't care about which makes VVB 6 a poor option in my opinion. It is because of those technical issues that I chose not to use it for my game projects and absolutely won't. For one thing you are probably unaware when Visual Basic 6 was created many of the ActiveX components it relies upon were compiled for 16-bit versions of Windows. While we have been lucky that Jim Kitchen, Aprone, and other VI developers have stayed clear of some of those older 16-bit ActiveX components there are many mainstream developers struggling to update their software products because they used older 16-bit ActiveX components in their VB 6 software that will absolutely positively not run on 64-bit versions of Vista, Windows 7, and Windows 8. The point here is that there are components and aspects of Visual Basic 6 that will not run on Windows 8 and just because we have been lucky so far doesn't mean everything written in that language will just work with no problems at all. Keep in mind that all new Pcs that you buy now either have Windows 7 or Windows 8 on them, and have a 64-bit processor. That means it won't be long before software developers like myself will have to begin writing software for 64-bit versions of Windows specifically. VB 6 was only designed for x86 32-bit processors and is holy unable to design software for the modern PC. Just because it will run in 32-bit compatibility mode does not mean it is the right tool for the job or that it will work as good as a program specifically designed for a 64-bit system. There are also bugs in the VB 6runtime libraries that are well known, but will never get fixed because Microsoft is no longer developing or maintaining those libraries. That means any software product or game based on Visual Basic 6 will potentially contain those bugs and there is no way to fix them other than rewrite the program from scratch in a different language. Finally, many of the technologies available to a VB 6 programmer such as DirectSound 8 are really showing their age and are not really suited to the task any more. It is well known that after Microsoft rewrote the mixer in Windows 7 and Windows 8 that DirectSound is broken. The 3d audio buffers no longer work meaning that if someone wants to write an FPS game like Shades of Doom with 3d audio VB 6 with DirectX 8 is a poor option on account of DirectSound being broken on newer versions of Windows. My point here is VB 6 was a great technology for its time, but it is time to let it go. I don't care if someone can get game developer x's programs to run on Windows 8 because that does not address the various problems with the underlying language and APIs. I personally feel it is time to walk away from the language, APIs, and tools and give something else better a try. I myself have chosen to go with C++ because it is the industry standard, has a great record of being easy to maintain over a long period of time, and works with more platforms than just Windows. So I have chosen to adopt C++ for my projects and my decision is not likely to change any time soon. It may have taken me a long time to figure out what I was going to use instead of .NET, but now that I have I have no intentions of adopting a language like VB 6 given its no longer supported and has a host of technical issues I would rather do without. --- 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].
