Why the iPad is no good
Posted by Mike | Filed under Commentary, Games, Programming
Well the news about the iPad has been around for a while, and there are plenty of game developers excited about it. Why? I haven’t the slightest clue. There is three differences between the iPhone/iPod touch and the iPad and they are: (A) Size of the screen (B) System power & (C) Price. The iPod Touch got more power between the first and second hardware revisions just like the iPhone 3G and 3GS. But, here is the problem… the iPad will bring about the downfall of the video game industry (if it actually catches on).
While my statement may be very wild, if the iPad actually catches on – video game developers should not be happy at all (at least the ones who want to make money). Sure, with the bigger screen size and more powerful system we’ll be able to make bigger and better games, but the problem is that the economics surrounding the iPad will probably gravitate to towards the same trends that the iPhone/iPod Touch have in terms of application costs and the flood of applications. While usually having more is better, in terms of the consumer, in the case of the App Store it is actually really bad. With the 20,000 games available on the App Store how can one find a good game? Its not easy. I put less research into buying a $60 game than I ever have trying to purchase a game from the App Store.
While the iPhone OS and SDK are great for indies and hopefuls wanting to break into the game industry, there are very few companies that can actually survive with the sort of economics that are available on the iPhone. The thing is, that you need to develop something really quick and really cheap in order to turn a profit. There are very few games that sell for more than a few dollars, so if your game cost $100,000 to make (not really that big of a number if you have an artist, programmer, QA, etc working on your game) then you would have to sell a minimum of ~150,000 if you sold your game at $0.99 (there is a percentage that Apple takes from the sale). Sure there are many developers that could put out games for less than $100K, but there are many people who will do this development on the side so there really isn’t any cost associated with it.
Now, you might be wondering why a a game developer would care about a platform they may not even develop for. Well, that is simple. The economics surrounding the App Store have started to bleed over into other sectors of the industry as consumer’s are getting more and more used to getting really small (and usually not that good games) for good and cheap. They want more of this. Now there are less and less people who are willing to continually spend $60 on a new release for a game. They might start buying used copies, none of which goes to the developer. And while I may be exaggerating a bit regarding the overflow, there are plenty of examples of people complaining about the price of the PSP minis in comparison to the App Store.
Now, the iPad has a touch interface, just like the iPhone. Guess what, it sucks. It doesn’t really drive innovation like one would think, except for innovation on how to adapt and get around the platform’s limitations. Sure limitations can drive people to create awesome games, but with the iPhone its about finding the interface that sucks the least. Yeah, the iPad has a much bigger screen that will allow developers greater flexibility when designing controls because screen space will not be as limited. The biggest problem with the iPad (in terms of gaming) is still present… NO BUTTONS. While the touch interface is great, it still needs to have physical buttons with physical feedback. No buttons = limited gaming potential.
Without forgetting one huge problem, we come to the biggest problem of all – PRICE. The starting price is $499 USD. That is more than a new desktop! This platform will suffer, just like the PS3 did, until it has a price cut to be a reasonable price that is affordable. The iPad is on track to have the same consumer adoption rate as the MacBook Air (while I don’t have numbers regarding this, many Mac enthusiasts that I know thought the device was a flop). You cannot charge $500 for a piece of hardware that doesn’t do that much and expect a huge adoption rate.
Lastly, we cannot forget the thing that I really cannot understand most of all – the lack of innovation in the device. What is the iPad really? It is an oversized iPod Touch. I think the only innovation is that it will be able to connect to the internet anywhere with AT&T – but that is not anything new. There are no new hardware innovations that will allow developers to create new interesting new interfaces. When the iPhone/iPod Touch came out at least the accelerometer and the multi-touch screen was new, now it is old and dull. In reality the iPad is nothing more than an oversized, overpriced, iPod Touch.
Tags: apple, Development, game development, Games, iPad, iPhone, iPod Touch, mac
NUnit x64/x86 Problems
Posted by Mike | Filed under Programming
Well I found a rather odd problem with NUnit as I was playing with it today. It seems that by default, the NUnit files are all built with the “Any CPU” setting. This means that if you are on a x64 system, the default is x64, and if you’re on a x86 its x86. This will cause problems if the settings don’t match your project settings. The error I kept receiving was:
could not load file or assembly “INSERT NAME HERE”. The tool exception tool was useless, and it too me forever to figure this one out. The only way I found it is because there is an explicit nunit*-x86 version of all the programs, I used that and after it worked I did some googling and found out why. Anyways, hopefully this is helpful to someone out there
Tags: NUnit, TDD, Unit Test, Unit Testing, x64, x86
Editing Visual Studio Menus
Posted by Mike | Filed under Programming, Random
I use Visual Assist X every time that I develop because it is one of the most amazing and useful plugins for Visual Studio, ever. However for some reason the context menu shortcut disappeared for some reason and it greatly slowed down my productivity. For a while I searched and tried to find a solution, and I finally did. Here is how to edit menus in Visual Studio:
If you click on main menu Tools -> Customize… The Customize window will open. Click on the Toolbars
tab at the top and select Context Menu by placing a check mark in its box on the left. This will place a ToolBar at the top of The IDE. Select Project and Solution Context Menus drop down list. Select the context menu to edit and then right click on the menu item to remove and select Delete. To Add menu items go to the Commands table of the Customize window Select a Categories and from the Commands section Drag and Drop the command in the same area you just deleted the previous. You will need to play around with it.
Tags: Context Menus, Editing Menus, visual studio
Unit Testing
Posted by Mike | Filed under Programming
I have been exploring the concept of unit testing for a little while now, and though it important to discuss. Unit testing is testing small parts of your code to ensure that there are no problems. There are many frameworks available freely on the internet, and usually come with enough of an introduction to get you off and going.
There are a few potential problems when it comes to unit testing. Some people claim that it can actually slow down your work, while others indicate that it speeds up their work and helps them produce better code. While I have never done extensive unit testing during the devlopment of the project, these two extremes in opinion seem to indicate that unit testing (and possibly test driven development in general) depends on the individual programmer.
To me there seems to be a few clear benefits, like if you are making small tweaks to optimize functions your unit tests could protect the function’s output from not remaining the same. This could be very helpful for long term development projects (like engines and frameworks) but maybe not so much for game development.
This seems like an interesting topic that definetly warrants further study.
Tags: c++, TDD, Test Driven Development, Testing, Unit Testing
Creating DLLs with Visual Studio
Posted by Mike | Filed under Programming
DLLs are an important part of the Windows Operating system that will allow a program to dynamically load and execute code. This means that you could build an executable one day, and still make updates without re-releasing it.
Creating a DLL isn’t really all that difficult, and it only takes a few steps. This guide is particular to C++ and Visual Studio, so I don’t know whether or not you could use the same process for other compilers.
The first step is to create the code that you want to use. You could create the class or the functions, it doesn’t really matter. Take a look at the following example:
class testClass
{
public:
void testingFunction();
};
Now, this is your standard C++ basic class (without any definitions for the class, this will not link properly if you attempt to use it). All that needs to be done to make this class ready to use with a DLL is to add the Microsoft code for exporting a function/clas with __declspec(dllexport). So this is what the result is…
#define DLL_EXPORT __declspec(dllexport)
class DLL_EXPORT testClass
{
public:
void testingFunction();
};
Now the only difference is that there is a macro that places the dll export call into the class. Now the great part about this method is that should you ever need to maintain a static library and a dynamic library, you’ll be able to not modify any code (except for the DLL_EXPORT macro).
All the code is now present and everything should work. When you build the DLL it should also automatically build a import library (a lib).
Tags: c++, dll, visual studio
C++ Language
Posted by Mike | Filed under Programming
I have heard many people claim that C++ is not a very good language to work with, mostly because it isn’t easy. As a professional game developer it is the standard language for developing with, and I know that I wouldn’t have it any other way. There are plenty of other languages out there, even some that are very similar to C/C++. However, C++ allows you to do a great multitude of things like operator overloading, type casting (although some think this is not a good idea), pointers, direct memory manipulation, and much more. C++ to me is like a blank slate. Is it hard to work with sometimes? Absolutely, that is why its a professional language.
Lets look at two other languages that are very similar to C/C++ that are supposed to improve upon them. The first is Objective C, Apple’s default language. When it comes to Objective C there are no constructors, and everything is init’d to a default value (booleans to false, number values to 0, etc). To set everything up, it has to be init’d – which is not always easy. Additionally, Objective C has dynamic type checking – THE WORST OPTION IN THE WORLD. If it won’t work at runtime, it shouldn’t compile!!! I mean, it would be great for porting stuff over from one project (or platform) to another, but other than that I don’t understand why you would ever want it.
Microsoft has a language called C#. First, C# is an interpreted language with the .NET framework. Therefore there is a massive problem right off the start. Secondly, the standard is not open, but is controlled by Microsoft. Should you want something that is as easy as C# and cross platform – go with Java and use something that a monopolistic giant doesn’t control. The automatic garbage collection is cool, but that feature is available in lots of other languages.
Although, if it weren’t so inefficient to program in Assembly that would probably be my choice. The reason that C++ is so great is that it is cross platform and is not an interpreted language. Of course there are difference in what you can do and how you must go about doing them.
C is also the standard language for most popular APIs like OpenGL, OpenAL, FMOD, SDL, DirectX (although it has bindings for C#&VB), and more. So… will C++ disappear anytime soon? Probably not.
Tags: apple, c++, microsoft, objc, programming languages
OpenGL Programming Guide
Posted by Mike | Filed under Books, Programming
OpenGL Programming Guide
Although I haven’t quite finished reading this behemoth of a book, what I have read so far has been quite impressive. This book is probably one of the most recognizable OpenGL books. This book is 1000 pages of API documentation mixed in with step by step learning and code samples. If you need a good OpenGL book to learn from, or just as a reference book, get this book.
Game Engines
Posted by Mike | Filed under Games, Programming
When it comes to game development, the most important part is the game engine. The game engine is what everything is built on top of, it is the heart of the game. While video game engines can come in many different shapes and sizes, the best video game engines are modular and easy to develop with. There are plenty of free game engines and game development software, but which ones are the best? What good ones are actually out there?
Ogre3D
This is more just a rendering engine than a full blown game engine. But graphics is usually the biggest challenge when it comes to game development. There is avery large community so there is plenty of help available when it is needed.
SDL
Simple direct media layer, is a multiplatform 2D Game Engine. There is plenty of code available and good documentation to help when you are stuck. Take a look at the website to see some games and examples.
Unity
I have never really used this one, but they have an iPhone version available along with browser based games. This is not a free engine, but the cost of the license is not prohibitive for a small company that is trying to develop a game.
Source Engine
A very well known engine, the Source Engine is available to anyone who can access Steam. I believe that you have to purchase a HL2 or something similar before you can have access to it. You don’t have access to the source code right away, but you can do some pretty amazing stuff with it nevertheless.
Irrlicht Engine
This is another open source engine and I haven’t used it. This open source engine seems to be a more complete engine, with a a small toolset. When browsing to the front page, you can see several game examples.
jMonkeyEngine
Despite the fact that I do not believe that Java can be used as a serious game development, that doesn’t preclude it from being used for hobbyist development.
Conclusion
Here are a few engines and open source tools for game development. Hopefully this is helpful foy anyone looking to do some game development.
Tags: engine, game engine, Irrlicht, Irrlicht Engine, jMonkeyEngine, libsdl, ogre3d, SDL, Source Engine, Unity, Unity Engine, video game development, video games
Unreal Development Kit
Posted by Mike | Filed under Games, Programming
The Unreal Engine 3, one of the most recognized “next gen” game engines, is now available for free to download. The UDK, available from Epic, now allows anyone to harness the power of the Unreal Engine for their own development. Have you ever wanted to create games on your own? Well now you can.
I haven’t tried this out yet, but I will be sure to post my comments when I have.
Tags: free, game development, game engine, udk, unreal, unreal engine 3
OpenAL Tutorial 1
Posted by Mike | Filed under Programming
This is a tutorial on OpenAL and how to use it. This will guide you through creating a basic audio engine with OpenAL for audio playback in games.
Introduction
OpenAL is an audio API for use with games (among other things). It is crossplatform and useful for positioning audio sources within a 3d world. OpenAL has a utility toolkit, similar to glut for OpenGL, called alut. This library is use. This tutorial will be broken up into several pieces to make it easier to digest and understand.
Lesson 1: Initalization and Basic Error Handling
The first thing that you need to do, when dealing with almost any API, is to initialize it for use. Because I am using the alut library in addition, we have two sets of APIs that we need to setup and initalize. The first thing to know is that there are two initalization options for alut, both which are documented below
ALboolean alutInit (int *argcp, char **argv);
Initializes the ALUT internals and creates an OpenAL context on the default device and makes it the current OpenAL context. If you want something more complex than that (e.g. running on a non-default device or opening multiple contexts on multiple devices), you can use alutInitWithoutContext instead. alutInit examines the commandline arguments passed to it and remove those it recognizes. It is acceptable to pass two NULL pointers in settings where no useful information can be obtained from argc and argv.
ALboolean alutInitWithoutContext (int *argcp, char **argv);
Initializes the ALUT internals. It does not create any OpenAL context or device, so this has to be done via the usual ALC calls. alutInitWithoutContext examines the commandline arguments passed to it and remove those it recognizes. It is acceptable to pass two NULL pointers in settings where no useful information can be obtained from argc and argv.
Basically one function (alutInit) will initalize both alut and OpenAL, and another will just initalize alut. Which function you use is your preference, but I prefer to initalize only alut with alut initalization routine, you could do the other. Please see the example below for initalizing alut.
Example 1-1
if (!alutInitWithoutContext(NULL, NULL))
{
ALenum error = alutGetError();
printf("AudioEngine: ERROR: There is a problem with alut. Audio not avaiable. ALUT Error: %s\n", alutGetErrorString(error));
}
All this code does it initalize alut only, without passing anything. If the alut init routine fails, it returns an ALboolean as false. Then check for the error and you can get an error string to help in your debugging.
Alright, now that alut is init’d, you can now move on to the actual initalization routine of OpenAL. There are a two basic steps you need to do to setup everything: First you need to open the device, and then create the context. First, lets begin with openning the device. You use the following function call
ALCdevice *alcOpenDevice(const ALCchar *devicename);
Which opens a device on the current system. devicename can be a string used to describe the current device, or NULL to obtain the system default. This can be used to specify a specific device, which you should rarely need to do. After opening the device, ensure that you check the current error state using:
ALCenum alcGetError(ALCdevice *device);
ALenum alGetError();
The device parameter is the return value from the alcOpenDevice function. After checking to ensure that we are still sane in our current state, we move on to the creation of our context. Again, this is pretty simple to do, and we need only two function:
ALCcontext * alcCreateContext(ALCdevice *device, ALCint* attrlist);
Which creates a new OpenAL context with the device you just accessed. The attrlist can be NULL (see the documentation for more information regarding the paramets). Then using this call:
ALCboolean alcMakeContextCurrent(ALCcontext *context);
we set the newly created context to be the one we want to use. And that is it! See Example 1-2 for the OpenAL init code
ALenum error;
ALCdevice* audioDevice = alcOpenDevice(NULL);
if((error = alcGetError(audioDevice)) != ALC_NO_ERROR)
{
printf("ERROR: There is a problem with the audio device, no audio will be available as a result: %s\n", alutGetErrorString(error));
}
if (audioDevice)
{
ALCcontext* curContext = alcCreateContext(audioDevice, NULL);
alcMakeContextCurrent(curContext);
if((error = alcGetError(audioDevice)) != ALC_NO_ERROR)
{
printf("ERROR: There is a problem with the audio context, no audio will be available as a result: %s\n", alutGetErrorString(error));
}
}
Excercise 1-1
The above code is not complete with all the necessary error handling code. Find and add in the appropriate error handling code
External Sources
Please note that alut API documentation came from the following website.
All documentation regarding OpenAL’s API came from the OpenAL Programmer Guide.
Tags: alut, alutinitwithoutcontext, audio, Games, OpenAL, OpenAL API, Programming, tutorial
RSS Feed