Jesse Shells gave a 30 minute talk about the future of games. This isn't your standard talk about "oh, hey, everyone is going to either have a holodeck or just have the games play in the mind." This is a more realistic look at gaming in the next twenty years. I must say though, that while it initially sounds awesome, I can't help but wonder if it is a path to our destruction.
The first nineteen minutes discuss what the current state of gaming is. It is insightful and I recommend watching it. However, if you want to get to the goods, skip to about the 19 minute mark.
http://fury.com/2010/02/jesse-shells-mindblowing-talk-on-the-future-of-games-dice-2010/
Wednesday, February 24, 2010
Wednesday, February 17, 2010
Ensuring higher-quality code
Reading Microsoft’s Many Eyeballs and the Security Development Lifecycle by Shawn Hernan has revealed some interesting practices that I should want to apply to my own personal programming efforts:
Most of this was grabbed from Microsoft's Security Development Lifecycle which included several other practices, but these seemed to be the best for a small team with a small budget working on a relatively unknown project that hasn't been seen by many users.
Static Analysis
Static analysis seems to me to be particularly handy in a one-man operation, since what it involves is running the code through some checks to make sure that everything is on the up and up. A good example is lint for C, Microsoft has a free one that works for .net apps, and Java has several good free ones like Checkstyle and FindBugs, but what about C++ developers? I'm thinking about trying out CppCheck, one of the several suggested by Stack Overflow #141498. Remember though, that not every bug listed is a true bug, there can be many false positives.
Dynamic Analysis
Dynamic analysis is also another useful tactic even in a one man project. Unlike static analysis, which looks at the code, dynamic analysis inspects the program when it is running. The best open-source example I can think of here is valgrind. This technique also has the same false positives issue that static analysis has.
Fuzz Testing
I first heard of fuzz testing when I read about one of the ways Google Chrome checks for errors. Other articles explain it better than I do here, but the gist is that varying amounts of random data are shoved into your program, and then you look at the results. For web apps, it would be random webpages or random text. For games, it could simulate mashing down on a keyboard or something. A quick search on Google revealed one open-source automated tool, zzuf, designed mostly for video and web apps.
Code Reviews
Shawn Hernan's article noted that code reviews are useful and do catch bugs, but not as many bugs as when both static and dynamic analysis are used. This has a problem with single developer projects because you need at least one other developer to review the authors code. In that case, the best the developer could do, I guess, is to wait a month or two and read the code again. Google Code has peer reviews built in, and I know SourceForge also has the option. If you have code on your own server, I've had great luck with Review Board.
In conclusion, when it comes to personal projects, these things I just mentioned are the least sexy concerns when it comes to development. We care about features and having them as soon as possible. I have yet to even start using them here at team pezad, but I have an interest to, because 1: It will make the programs more reliable and therefore friendly to its users and 2: It will make me a better programmer, and I'd like to think more marketable as well.
Squish the bugs, and you'll have more room for richer, healthier features. That's my theory!
- Static Analysis
- Dynamic Analysis
- Fuzz Testing
- Code Reviews
Most of this was grabbed from Microsoft's Security Development Lifecycle which included several other practices, but these seemed to be the best for a small team with a small budget working on a relatively unknown project that hasn't been seen by many users.
Static Analysis
Static analysis seems to me to be particularly handy in a one-man operation, since what it involves is running the code through some checks to make sure that everything is on the up and up. A good example is lint for C, Microsoft has a free one that works for .net apps, and Java has several good free ones like Checkstyle and FindBugs, but what about C++ developers? I'm thinking about trying out CppCheck, one of the several suggested by Stack Overflow #141498. Remember though, that not every bug listed is a true bug, there can be many false positives.
Dynamic Analysis
Dynamic analysis is also another useful tactic even in a one man project. Unlike static analysis, which looks at the code, dynamic analysis inspects the program when it is running. The best open-source example I can think of here is valgrind. This technique also has the same false positives issue that static analysis has.
Fuzz Testing
I first heard of fuzz testing when I read about one of the ways Google Chrome checks for errors. Other articles explain it better than I do here, but the gist is that varying amounts of random data are shoved into your program, and then you look at the results. For web apps, it would be random webpages or random text. For games, it could simulate mashing down on a keyboard or something. A quick search on Google revealed one open-source automated tool, zzuf, designed mostly for video and web apps.
Code Reviews
Shawn Hernan's article noted that code reviews are useful and do catch bugs, but not as many bugs as when both static and dynamic analysis are used. This has a problem with single developer projects because you need at least one other developer to review the authors code. In that case, the best the developer could do, I guess, is to wait a month or two and read the code again. Google Code has peer reviews built in, and I know SourceForge also has the option. If you have code on your own server, I've had great luck with Review Board.
In conclusion, when it comes to personal projects, these things I just mentioned are the least sexy concerns when it comes to development. We care about features and having them as soon as possible. I have yet to even start using them here at team pezad, but I have an interest to, because 1: It will make the programs more reliable and therefore friendly to its users and 2: It will make me a better programmer, and I'd like to think more marketable as well.
Squish the bugs, and you'll have more room for richer, healthier features. That's my theory!
Sunday, February 14, 2010
CNBC and video games
I've watched two shows on CNBC about the video game industry. The first was Game On, a segment on video game history. After that show finished, they showed Playing to Win, which covered more about modern game trends.
I'm glad they didn't just show stock footage of Doom, there was actually some good stuff in there. For instance, I've never seen the vector graphics of the original video game, Spacewar!. They even had interviews with Ralph Baer, Nolan Bushnell, and somebody else, probably. One of the things I hadn't known about was that Steve Jobs was involved in the making of Breakout, which was back in his hippy days.
Overall they presented the topics in a mostly balanced level. But why in the world though, did they decide to use Mortal Kombat music for their bumper music? On both shows? For almost every bumper?
I'm glad they didn't just show stock footage of Doom, there was actually some good stuff in there. For instance, I've never seen the vector graphics of the original video game, Spacewar!. They even had interviews with Ralph Baer, Nolan Bushnell, and somebody else, probably. One of the things I hadn't known about was that Steve Jobs was involved in the making of Breakout, which was back in his hippy days.
Overall they presented the topics in a mostly balanced level. But why in the world though, did they decide to use Mortal Kombat music for their bumper music? On both shows? For almost every bumper?
Subscribe to:
Posts (Atom)