The Space Station Defence game that has just been posted on Blazing Games is not the game that I planned to release in March. I was actually planning on releasing another episode of Dozen Days of Words, possibly both of the final episodes. After just starting work on episode 11, I came up with a concept for an arcade game. I figured I would take a few hours and build a quick prototype of this game. While assembling the prototype, I realized that the game would simply not be fun. Before dropping my prototype, I went for a walk as in the Okanagan Valley we are having an unusually warm winter with all our snow melted already. While some people may blame our warm weather on global warming, I know that the real reason is because I bought a bunch of exercise games for my Wii. While I have lost a lot of weight, I still have a way to go. My own long history of dieting has taught me that the only way I can lose weight and keep it off is by exercising. Now that I have audiobooks and podcasts to listen to while walking, I have drastically increased the amount of exercise I do. While this might not seem to have anything to do with game development, walking helps my mind sort through it's myriad of thoughts. A simple change turned a dead prototype into a released game.
The original concept was a shield game. The player would have a shield around their space station. This shield would slowly recover but could be rotated. As the player took damage, they would simply rotate the shield. In theory this sounds interesting. The problem is that actual game-play isn't much fun.
During my walk, I came up with two different solutions. The first would be to have a non-destructible shield but one that only protected a small portion of the space station. The other method was to slow down shield recharging and give the player missiles to shoot back. As the later idea sounded more fun I went with that. The game lasted too long with recharging shields, so in fine tuning I removed that feature. As I already had three different shield levels, I also opted to have three different difficulty levels. I think another pass or two would have been nice, but I simply have not had the time.
Does this mean that the eleventh episode of Dozen Days of Words is going to be released in April? To be honest, I don't know. I do want to start experimenting with HTML5 so I hope to have a game that takes advantage of the canvas element. This feature is already supported by most browsers, and there is a JavaScript library that adds canvas support to Internet Explorer. Microsoft seems to be exceedingly slow at adding HTML5 features to their browser. I suspect they are trying to shove Silverlight down everyone's throat. HTML5 would make Silverlight mostly irrelevant. To be honest, I am starting on my HTML5 migration much sooner than I ever anticipated largely due to Mozilla, Google and Apple's push for HTML5 features.
Sunday, February 28, 2010
Sunday, February 21, 2010
Programming, the Early Years
Efficient code is not as important as it use to be. What is worse is that the situation is getting worse not better. While the vital parts of a program are likely to be written efficiently, a growing percentage of the code is going to be quickly written and probably inefficient. Making this situation even worse is that the code being written is often going to be interpreted or ran on a virtual machine. To understand why this is the case and why things will get worse before they get better one just has to look at how programming has evolved over the years.
The earliest computers were programmed in machine language. In the very early days this was done by re-wiring machine components though this quickly changed to flipping switches and then into punched cards or paper tape. Computers were huge expensive machines so every second of machine time was precious. Programs were often ran in batches meaning that you would submit your cards or tape and wait (sometime days or weeks) to get your results. When you got your results, if there were problems then you would have to re-submit. As computer time was golden, sloppy code was frowned upon. Likewise, because there was a fair amount of time between tests, programmers had plenty of time to make sure their code was well written.
Computer programs were much simpler back then due to the fact that the machines had almost no memory and were slow. Memory in early computers were measured in Kilo-words with the number of bits in a word being machine specific though 18 seemed to be a common number. A gigabyte is 1,048,576 kilobytes or 1,073,741,824 bytes so to think back in terms of kilo-words is scary. Speed was in kilohertz. Yes, a gigahertz is 1,000,000 kilohertz. Still, programming in Machine Language would have been painful work. What most programmers did was write their programs in an English-like format where machine instructions were given simple names such as LOAD, STORE, JUMP. This code was then converted into the numbers that had to be put into the computer.
Hand coding machine language was a big waist of programmer time, but the cost of programmers was a lot less than the machines that were being programmed. I am sure that many early programmers came up with the idea of a tool that would take a human readable form of machine language and converting it into the actual machine language instructions. It wasn 't until the 1950s that such programs started being used. This made programming much more efficient. When a program was written in assembly language, it had to be run through a program called an assembler which converted a human-readable form of machine language into a machine-readable form of machine language. While this added an extra step to the process, the assembly step only had to be done once and the resulting output could then be used any number of times. The assembler resulted in boosted productivity for the programmers.
The cost of computers began to decline while the capabilities continued to grow. This resulted in computers becoming more common. Soon big business and research facilities all wanted to have their own computers. The problem with computers then became the requirement for programmers to write the programs in assembly language (which at this point was starting to be referred to as machine language even though technically speaking there is a difference). If only there was a way for "normal" people to write programs.
This article will continue in a couple of weeks as next week I will be writing about the March release on Blazing Games which is a game that came from a quick protoype I created. This game is an example of how plans for a game can drastically change.
The earliest computers were programmed in machine language. In the very early days this was done by re-wiring machine components though this quickly changed to flipping switches and then into punched cards or paper tape. Computers were huge expensive machines so every second of machine time was precious. Programs were often ran in batches meaning that you would submit your cards or tape and wait (sometime days or weeks) to get your results. When you got your results, if there were problems then you would have to re-submit. As computer time was golden, sloppy code was frowned upon. Likewise, because there was a fair amount of time between tests, programmers had plenty of time to make sure their code was well written.
Computer programs were much simpler back then due to the fact that the machines had almost no memory and were slow. Memory in early computers were measured in Kilo-words with the number of bits in a word being machine specific though 18 seemed to be a common number. A gigabyte is 1,048,576 kilobytes or 1,073,741,824 bytes so to think back in terms of kilo-words is scary. Speed was in kilohertz. Yes, a gigahertz is 1,000,000 kilohertz. Still, programming in Machine Language would have been painful work. What most programmers did was write their programs in an English-like format where machine instructions were given simple names such as LOAD, STORE, JUMP. This code was then converted into the numbers that had to be put into the computer.
Hand coding machine language was a big waist of programmer time, but the cost of programmers was a lot less than the machines that were being programmed. I am sure that many early programmers came up with the idea of a tool that would take a human readable form of machine language and converting it into the actual machine language instructions. It wasn 't until the 1950s that such programs started being used. This made programming much more efficient. When a program was written in assembly language, it had to be run through a program called an assembler which converted a human-readable form of machine language into a machine-readable form of machine language. While this added an extra step to the process, the assembly step only had to be done once and the resulting output could then be used any number of times. The assembler resulted in boosted productivity for the programmers.
The cost of computers began to decline while the capabilities continued to grow. This resulted in computers becoming more common. Soon big business and research facilities all wanted to have their own computers. The problem with computers then became the requirement for programmers to write the programs in assembly language (which at this point was starting to be referred to as machine language even though technically speaking there is a difference). If only there was a way for "normal" people to write programs.
This article will continue in a couple of weeks as next week I will be writing about the March release on Blazing Games which is a game that came from a quick protoype I created. This game is an example of how plans for a game can drastically change.
Sunday, February 14, 2010
Is Trivia Trivial?
The enhanced version of history bomb has been posted on Blazing Games. My rant on efficient programming will continue next week, this week I am going to talk a bit about trivia as the game just releases is a type of trivia game.
On the surface, trivia games seem to be something that is easy to create. As someone who has written a fair number of them, some for third parties, my knowledge of the subject is fairly high. Programming a trivia game is in fact very simple. The game logic for a trivia game is in fact trivial to write. The server-side database/score handling and the user interface were what took up the vast majority of time. This makes sense when you think about it as ultimately trivia is just a variation of the simplest of all computer games. That game being the pick-a-number game. The difference is that the numbers are answers and random numbers are used to scramble the potential answers. There is one thing that makes the trivia games on my site different from the third-party games that I have written. For the third-party games I wrote, I didn't have to come up with questions.
Coming up with the questions for a trivia game may sound simple but it is a fairly time-consuming process. First you need to come up with a subject that you think that the people playing the game will be interested in that you also have some knowledge of. Next you have to come up with a question. This would be similar to writing a question for a test, except the question has to fit a particular format. In Trivia Bomb it was a simple multiple-choice question. History Bomb, on the other hand, is a sorted list. I will say that multiple-choice is much easier to come up with questions as one only needs to make sure his or her answer is correct then come up with wrong answers. Sure, it is time consuming, but it is very flexible. Lists requires finding something that has a distinct order to it. Then verifying that order. In some cases, this meant not only researching the subject, but then having to do additional research on each item on the list.
The bright side, though, is that the extended version of History Bomb has no time limit for its development. When the game-in-a-day pressure is removed, researching questions was much more enjoyable though probably even more time consuming. What trivia-question-writers probably don't want you to know is that just diving into a subject to verify facts often leads to much further exploration of a topic. I suppose there is the obvious "looking for other potential questions" excuse.
While coming up with questions is not hard work, it is time consuming work. Still, when creating a trivia game, it is probably best to remember that the questions are going to have to be created (unless you do the low-life thing and steal questions from other people). When I play a trivia game in the future, I am going to remember that each question probably took far longer to create then I will ever spend answering it.
On the surface, trivia games seem to be something that is easy to create. As someone who has written a fair number of them, some for third parties, my knowledge of the subject is fairly high. Programming a trivia game is in fact very simple. The game logic for a trivia game is in fact trivial to write. The server-side database/score handling and the user interface were what took up the vast majority of time. This makes sense when you think about it as ultimately trivia is just a variation of the simplest of all computer games. That game being the pick-a-number game. The difference is that the numbers are answers and random numbers are used to scramble the potential answers. There is one thing that makes the trivia games on my site different from the third-party games that I have written. For the third-party games I wrote, I didn't have to come up with questions.
Coming up with the questions for a trivia game may sound simple but it is a fairly time-consuming process. First you need to come up with a subject that you think that the people playing the game will be interested in that you also have some knowledge of. Next you have to come up with a question. This would be similar to writing a question for a test, except the question has to fit a particular format. In Trivia Bomb it was a simple multiple-choice question. History Bomb, on the other hand, is a sorted list. I will say that multiple-choice is much easier to come up with questions as one only needs to make sure his or her answer is correct then come up with wrong answers. Sure, it is time consuming, but it is very flexible. Lists requires finding something that has a distinct order to it. Then verifying that order. In some cases, this meant not only researching the subject, but then having to do additional research on each item on the list.
The bright side, though, is that the extended version of History Bomb has no time limit for its development. When the game-in-a-day pressure is removed, researching questions was much more enjoyable though probably even more time consuming. What trivia-question-writers probably don't want you to know is that just diving into a subject to verify facts often leads to much further exploration of a topic. I suppose there is the obvious "looking for other potential questions" excuse.
While coming up with questions is not hard work, it is time consuming work. Still, when creating a trivia game, it is probably best to remember that the questions are going to have to be created (unless you do the low-life thing and steal questions from other people). When I play a trivia game in the future, I am going to remember that each question probably took far longer to create then I will ever spend answering it.
Friday, February 5, 2010
Is efficient code obsolete?
I was looking over some of my older code noting how inefficient some of my code was. There were a number of reasons for this. The biggest is my very short development time. In my case, the short schedules are the result of my desire to release a lot of material. I have tried to slow down my release schedule to allow for better content, but other things always seem to creep in to steal my spare time. Unrealistic schedules are far too common in the tech industry and is made worse by the fact that the vast majority of people in charge have no clue how software works or how much work is involved in its creation. Making this problem worse are the programmers themselves who often vastly under-estimate the work required to complete a project. Short development time leads to focusing on just getting the code to work not on getting the code to work as efficiently as possible.
Related to the short development time is the fact that often I will cut and paste similar code from earlier projects that I have worked on. I restrict myself to code that I have written, though there are many programmers who will cut and paste from other peoples' code. By tweaking existing code, you can implement something very quickly. The problem is that often the code you are borrowing may have stuff in it that you are not using within the new project but that was necessary in the original project. The fact that you are cutting and pasting code probably means you are in a hurry which means that the redundant and unnecessary code that is copied will remain resulting in both code bloat and inefficient code. Changing project specifications in the middle of a project, which is sadly far to common, also results in unnecessary code bloat for similar reasons.
A third common reason for my inefficient code is that the code in question is not going to be executed very often. This is related to the first reason due to the obvious fact that functions that are infrequently used are going to be written fairly quickly. Another reason that infrequently executed code tends to be inefficient is that there is very little incentive to optimize the code as the inefficiency of rarely executed code is not going to noticeably impact the overall speed of the program. Optimising a program takes time so that effort should be placed on the parts of a program that are executed frequently or that are most critical to the speed of a program.
Not all of my reasons are related to development time. I often will write code that I can easily understand instead of using more efficient code that was harder to grok. For example:
c = Math.min(a,b);
This code obviously sets c to be the lower of the values a or b. It is, however, making a function call which has overhead and if the function call uses floating point while the variables used are integer you have a number of type conversions as well. Many languages have generics and will inline small code blocks right into the code if compiler optimisation is enabled which can mitigate the speed difference. In the best case, the compiler would essentially convert the function call into the following statement:
c = (a < b) ? a : b;
If you were to use the second version of the code instead of the first, you would be guaranteed no function call or type conversion overhead. I find first version much easier to understand, but depending on your compiler it could be substantially slower than the second version. The difference is in the millionth of a second, though.
None of this even gets into the facts that the code being written is often going to be interpreted or ran on a virtual machine. Likewise, the speed of computers is not looked at. Worst of all, the fact that programmers are no longer familiar with low level programming so write code that doesn't compile efficiently is not addressed. Those are topics for another column or three. Still, the conclusion that I have come up with is the simple one that computer time is far cheaper than programmer time which is cheaper than time-to-market time so it is safe to say that while writing efficient code is still something to be aimed for, getting code out quickly is sadly the bigger priority.
Related to the short development time is the fact that often I will cut and paste similar code from earlier projects that I have worked on. I restrict myself to code that I have written, though there are many programmers who will cut and paste from other peoples' code. By tweaking existing code, you can implement something very quickly. The problem is that often the code you are borrowing may have stuff in it that you are not using within the new project but that was necessary in the original project. The fact that you are cutting and pasting code probably means you are in a hurry which means that the redundant and unnecessary code that is copied will remain resulting in both code bloat and inefficient code. Changing project specifications in the middle of a project, which is sadly far to common, also results in unnecessary code bloat for similar reasons.
A third common reason for my inefficient code is that the code in question is not going to be executed very often. This is related to the first reason due to the obvious fact that functions that are infrequently used are going to be written fairly quickly. Another reason that infrequently executed code tends to be inefficient is that there is very little incentive to optimize the code as the inefficiency of rarely executed code is not going to noticeably impact the overall speed of the program. Optimising a program takes time so that effort should be placed on the parts of a program that are executed frequently or that are most critical to the speed of a program.
Not all of my reasons are related to development time. I often will write code that I can easily understand instead of using more efficient code that was harder to grok. For example:
c = Math.min(a,b);
This code obviously sets c to be the lower of the values a or b. It is, however, making a function call which has overhead and if the function call uses floating point while the variables used are integer you have a number of type conversions as well. Many languages have generics and will inline small code blocks right into the code if compiler optimisation is enabled which can mitigate the speed difference. In the best case, the compiler would essentially convert the function call into the following statement:
c = (a < b) ? a : b;
If you were to use the second version of the code instead of the first, you would be guaranteed no function call or type conversion overhead. I find first version much easier to understand, but depending on your compiler it could be substantially slower than the second version. The difference is in the millionth of a second, though.
None of this even gets into the facts that the code being written is often going to be interpreted or ran on a virtual machine. Likewise, the speed of computers is not looked at. Worst of all, the fact that programmers are no longer familiar with low level programming so write code that doesn't compile efficiently is not addressed. Those are topics for another column or three. Still, the conclusion that I have come up with is the simple one that computer time is far cheaper than programmer time which is cheaper than time-to-market time so it is safe to say that while writing efficient code is still something to be aimed for, getting code out quickly is sadly the bigger priority.
Subscribe to:
Posts (Atom)
