Sunday, January 30, 2011
Procrastination and the flu
I am writing this on my laptop while lying in bed. I have been suffering the last few days with a bad cold or possibly the flu. While I have the code that I am writing about finished, I haven't pre-written the posts. I intended to get ahead with my articles so that when I became busy, or other things came up, I would be able to make the post anyway. Despite always being busy, I guess I still have some procrastination problems. My sister once told me "don't drink and hard drive." This probably also applies to writing technical articles when you have the flu. So my DDT series will again be postponed, but at least I haven't broken my new years resolution.
Sunday, January 23, 2011
Pushing Buttons
While the title of today's post could describe my feelings toward Neverwinter Nights 2, it has been too long since I went over my work on Dozen Days of Tiles. Still, one of the best ways to improve your design skills is to look at problems other games have so I will probably take a break in the future and look at how NWN2 could have been a much better game.
While the work involved in coding my user interface components didn't take long at all, explaining the decisions that I made will take a bit of time so the next few articles will be more focused on my thought-process than on coding as a lot of options were available. Like with most things in life, there is no one best way of doing things.
When it comes to user interface components, everything revolves around buttons. If you can create a versatile button, it is easy to extend that component to form much more complicated components. So the first thought is how will the button work. On the surface, buttons only have 2 states. They can be up or down. When developing low level interface on other platforms, I have always had a third state. Disabled. In fact, when I started playing around with Flash, I was shocked to discover that it didn't have a disabled state for buttons. I tended to just make Flash buttons invisible when de-active, but a better solution is to have a disabled image underneath the button so that when made invisible there would be a visible "disabled" version of the button visible. I always intend to do this but usually would run out of development time before doing this.
The purpose of having a disabled state is to let the user know that the option exists but is not appropriate at the time. While such a state is not absolutely necessary, it is a nice feedback mechanism and doesn't cost much so it is worth supporting. It is also handy for larger projects so future features can be put into the interface and disabled until implemented.
While the default Flash buttons do not support a disabled state, they do have an over state which allows the button to look different when the mouse is over it. As we move towards touch devices, this feedback no longer exists as most touch devices have no idea where your finger is until you actually touch the device. For mice/trackpad users, this is a really nice feedback mechanism so is well worth supporting.
This means that we need to worry about four states. Disabled, Normal, Over, and Pushed. If we were creating an image-button, such a button would need four images to cover the display requirements. For a more general-purpose button, it is a bit more complicated than that but we will cover that next time.
While the work involved in coding my user interface components didn't take long at all, explaining the decisions that I made will take a bit of time so the next few articles will be more focused on my thought-process than on coding as a lot of options were available. Like with most things in life, there is no one best way of doing things.
When it comes to user interface components, everything revolves around buttons. If you can create a versatile button, it is easy to extend that component to form much more complicated components. So the first thought is how will the button work. On the surface, buttons only have 2 states. They can be up or down. When developing low level interface on other platforms, I have always had a third state. Disabled. In fact, when I started playing around with Flash, I was shocked to discover that it didn't have a disabled state for buttons. I tended to just make Flash buttons invisible when de-active, but a better solution is to have a disabled image underneath the button so that when made invisible there would be a visible "disabled" version of the button visible. I always intend to do this but usually would run out of development time before doing this.
The purpose of having a disabled state is to let the user know that the option exists but is not appropriate at the time. While such a state is not absolutely necessary, it is a nice feedback mechanism and doesn't cost much so it is worth supporting. It is also handy for larger projects so future features can be put into the interface and disabled until implemented.
While the default Flash buttons do not support a disabled state, they do have an over state which allows the button to look different when the mouse is over it. As we move towards touch devices, this feedback no longer exists as most touch devices have no idea where your finger is until you actually touch the device. For mice/trackpad users, this is a really nice feedback mechanism so is well worth supporting.
This means that we need to worry about four states. Disabled, Normal, Over, and Pushed. If we were creating an image-button, such a button would need four images to cover the display requirements. For a more general-purpose button, it is a bit more complicated than that but we will cover that next time.
Friday, January 14, 2011
MaXplosion vs 'Splosion Man
I posting my January 16th entry early and yet again am taking a break from DDT (though will probably be working on it this weekend). There is a bit of a controversy about a game Capcom released and its similarity to an indie game released by Twisted Pixel. The article http://arstechnica.com/gaming/news/2011/01/capcom-saddened-by-its-own-apparent-theft-of-splosion-man.ars covers this in some detail with video clips. I just wanted to express my opinion on this and it is definitely game-development related.
First off, I would like to say that MaXplosion is very clearly inspired by 'Splosion Man. In fact the single unique feature that 'Splosion Man introduced and which it's game-play revolves around is the distinguishing feature of MaXplosion. One could argue that using explosions to propel yourselves was introduced with Quake over a decade ago is probably a moot point. Or is it? Every element in 'Splosion Man has been borrowed from other games. Some people have pointed out that it is a platforming game which is derivative of Super Mario Bros. Even the Mario games were not the first platforming games, just the best known ones. I believe Apple Panic, Lode Runner, Jump-man, and Pitfall all came before it. So why is it okay for 'Splosion Man to derive it's gameplay elements from other games but not okay for MaXplosion?
That said, MaXplsion is very clearly a rip-off of 'Splosion Man. Capcom could have easily afforded to hire Twisted Pixel to develop the game for them or even bought them out. They are claiming that the Mobile division was unaware of Twisted Pixels proposals to Capcom. Having had some experience with corporations, I sort of believe them. Here is what I think happened. It is my opinion based on my personal experience so how well it corresponds with reality is debatable.
Capcom Mobile is told to start developing new IP by Capcom. They take a look at games on other platforms and see 'Splosion Man. They start developing a clone of it. Months later Twisted Pixel wants to expand to other consoles/markets and make a proposal to Capcom. Capcom knows that MaXplsion is in development already so refuse the offer instead of doing the right thing by canceling the project and making a deal with Twisted Pixel.
As usual, the small developer is left in the cold. While legally Capcom did nothing wrong, they did behave poorly. The only real thing that can be done is to buy 'Splosion Man while avoiding MaXplosion. Ultimately, though, people have to realize that the game industry is made up of derivatives of older games. There really are very few new ideas out there. Most of those ideas, however, come from the small independent developers so it is important to support them.
First off, I would like to say that MaXplosion is very clearly inspired by 'Splosion Man. In fact the single unique feature that 'Splosion Man introduced and which it's game-play revolves around is the distinguishing feature of MaXplosion. One could argue that using explosions to propel yourselves was introduced with Quake over a decade ago is probably a moot point. Or is it? Every element in 'Splosion Man has been borrowed from other games. Some people have pointed out that it is a platforming game which is derivative of Super Mario Bros. Even the Mario games were not the first platforming games, just the best known ones. I believe Apple Panic, Lode Runner, Jump-man, and Pitfall all came before it. So why is it okay for 'Splosion Man to derive it's gameplay elements from other games but not okay for MaXplosion?
That said, MaXplsion is very clearly a rip-off of 'Splosion Man. Capcom could have easily afforded to hire Twisted Pixel to develop the game for them or even bought them out. They are claiming that the Mobile division was unaware of Twisted Pixels proposals to Capcom. Having had some experience with corporations, I sort of believe them. Here is what I think happened. It is my opinion based on my personal experience so how well it corresponds with reality is debatable.
Capcom Mobile is told to start developing new IP by Capcom. They take a look at games on other platforms and see 'Splosion Man. They start developing a clone of it. Months later Twisted Pixel wants to expand to other consoles/markets and make a proposal to Capcom. Capcom knows that MaXplsion is in development already so refuse the offer instead of doing the right thing by canceling the project and making a deal with Twisted Pixel.
As usual, the small developer is left in the cold. While legally Capcom did nothing wrong, they did behave poorly. The only real thing that can be done is to buy 'Splosion Man while avoiding MaXplosion. Ultimately, though, people have to realize that the game industry is made up of derivatives of older games. There really are very few new ideas out there. Most of those ideas, however, come from the small independent developers so it is important to support them.
Sunday, January 9, 2011
The Preminition Problem
I am taking a break from my DDT discussion to instead discuss a design flaw in a game that I am currently playing. This is an older game that just recently became available on Steam in a platinum edition. As this game was one of the games on sale in the Steam end of the year sales, I grabbed it and a number of other games that I plan to eventually get around to. The game in question is Neverwinter Nights 2. I am a bit over twenty hours into the game and appear to have found a major design flaw in this game. I am hoping that this flaw isn't real, but have the gut feeling that it is and that as a result of this flaw my game experience is going to be sub-optimal for my first play through. The problem is that the game expects you to do something before you have any inkling that such an action needs to be done. This in itself isn't bad, but the locations that you have to do these thing in disappear from your map before it is revealed. This is an inexcusable design flaw.
In NWN2, the thing you need to be looking for is ore. Clicking on the ore game a small xp bonus, but without knowing that I should be searching for the ore, I missed some ore in locations that I can no longer go back to. I can only hope that the missed ore is not needed and more of a bonus for people playing through the game a second time. The basic rule of thumb is that you should never punish users for something unless they have been warned beforehand.
Having some element of a game present before-hand but revealed later is certainly an acceptable and rewarding experience if it is handled properly. In NWN2s case, this could have been done by simply not removing locations with ore on them from the map. Players should never be twenty or more hours into playing a game only to suddenly discover they missed out on something and the only way to get that something is to replay those twenty hours.
In NWN2, the thing you need to be looking for is ore. Clicking on the ore game a small xp bonus, but without knowing that I should be searching for the ore, I missed some ore in locations that I can no longer go back to. I can only hope that the missed ore is not needed and more of a bonus for people playing through the game a second time. The basic rule of thumb is that you should never punish users for something unless they have been warned beforehand.
Having some element of a game present before-hand but revealed later is certainly an acceptable and rewarding experience if it is handled properly. In NWN2s case, this could have been done by simply not removing locations with ore on them from the map. Players should never be twenty or more hours into playing a game only to suddenly discover they missed out on something and the only way to get that something is to replay those twenty hours.
Saturday, January 1, 2011
Re-inventing the Wheel
Happy New Year everyone. My resolution for the new year is to try and post at least once a week, most likely on Sundays but I am posting this a day early due to the date.
I am one of those programmers who suffers from Not Invented Here (NIH) Syndrome. This is a common affliction where programmers tend to prefer writing their own code rather than using existing libraries. In my case this condition was the result of having to use too many bad libraries earlier in my carrier so even though there are really good programming libraries available, many free or open source, the third degree burns from the past make me leery. The worst case for me was a deadlock which occurred in a very expensive library that a company I was doing consulting work for was using. There is nothing more awful then having a deadlock condition in your code only to find that the deadlock is happening in the library you are using for which you have no source code. This is probably a better reason for open source than Richard Stallman's reason.
The problem with NIH Syndrome is that time is spent writing your own libraries instead of using perfectly good libraries which already exist. Sometimes there are good reasons not to use the libraries so the opposite affliction also exists and is a worse condition as it leads to far too many script-kiddies. It is my opinion that there is nothing worse than a "programmer" who simply is not able to program. Still, it is always important to take a look at the requirements for your program and decide if using a third party library is appropriate or if your requirements are best served by reinventing the wheel.
In the case of Dozen Days of Tiles, the situation is not exactly the same as it isn't libraries that are being considered but whether to use HTML Form tags and CSS3 to handle the buttons and checkboxes or if custom code should be written. Still, knowing my NIH problem, thought had to be made about this.
The HTML Tags for buttons and checkboxes exist, and are easy to use. With CSS3 it is possible to have vast control over the look, feel, and positioning of these elements. The problem is that the rendering is done by the browser and are not part of the canvas. When you add the fact that games are visual in nature so being able to control all aspects of the interface are important, this lack of control and potential problems that having to deal with browser compatibility is probably a good enough reason to write some simple user interface classes. My own biases probably are a big factor in this decision, but it should only take a couple of hours to do the work so it isn't that big of a cost.
So with my poor rational for the decision is out of the way, the next step in the sudoku player is to write some user interface code.
I am one of those programmers who suffers from Not Invented Here (NIH) Syndrome. This is a common affliction where programmers tend to prefer writing their own code rather than using existing libraries. In my case this condition was the result of having to use too many bad libraries earlier in my carrier so even though there are really good programming libraries available, many free or open source, the third degree burns from the past make me leery. The worst case for me was a deadlock which occurred in a very expensive library that a company I was doing consulting work for was using. There is nothing more awful then having a deadlock condition in your code only to find that the deadlock is happening in the library you are using for which you have no source code. This is probably a better reason for open source than Richard Stallman's reason.
The problem with NIH Syndrome is that time is spent writing your own libraries instead of using perfectly good libraries which already exist. Sometimes there are good reasons not to use the libraries so the opposite affliction also exists and is a worse condition as it leads to far too many script-kiddies. It is my opinion that there is nothing worse than a "programmer" who simply is not able to program. Still, it is always important to take a look at the requirements for your program and decide if using a third party library is appropriate or if your requirements are best served by reinventing the wheel.
In the case of Dozen Days of Tiles, the situation is not exactly the same as it isn't libraries that are being considered but whether to use HTML Form tags and CSS3 to handle the buttons and checkboxes or if custom code should be written. Still, knowing my NIH problem, thought had to be made about this.
The HTML Tags for buttons and checkboxes exist, and are easy to use. With CSS3 it is possible to have vast control over the look, feel, and positioning of these elements. The problem is that the rendering is done by the browser and are not part of the canvas. When you add the fact that games are visual in nature so being able to control all aspects of the interface are important, this lack of control and potential problems that having to deal with browser compatibility is probably a good enough reason to write some simple user interface classes. My own biases probably are a big factor in this decision, but it should only take a couple of hours to do the work so it isn't that big of a cost.
So with my poor rational for the decision is out of the way, the next step in the sudoku player is to write some user interface code.
Subscribe to:
Posts (Atom)
