FInishing a Game

This fellow, Derek Yu of Mossmouth, has written an article called Finishing a Game. It's a worthy 5-10 minute read for any potential game developer.

I liked it so much I've written a summary of his summary. Be sure to check his article for the neato drawings of which I have none. Also his is funny.

1. Finishing is a skill, just like programming, drawing, or music composition.
2. Make a game that you want to make, but also one that you're capable of making, even if it is slightly out of your comfort zone.
3. When you "start the game," this means you can play the game in some fashion. You don't just have a game engine, a fancy written spec, or art assets.
4. Avoid making your own technologies when something out there already exists and fits your needs just fine.
5. The sooner you get a "working game" which allows you to prototype various game mechanics, the sooner you find out which ones are good ideas, which ones are bad, and which ones that give you ideas for better mechanics.
6. Do not choose partners based on skill alone. Consider how your personalities mesh, his experience in game creation, and your mutual interest in seeing the game completed.
7. Making a game be fun does not mean that it will always be fun making the game. Keep pushing yourself.
8. Have a deadline, and do not base it on a purely arbitrary date. Base it on competition events, for example.
9. Care for your well-being first. Keep eating, sleeping, exercising, etc.
10. Do not keep starting over the project. Just because you've gained so much knowledge since you first started the project doesn't mean you should scrap all previous programming work and start over. Fix only parts of it as needed. 
11. You will always feel that you could have coded something better.
12. If you have an idea for the game radical enough that you'd need to re-implement the entire game, or would incur a lengthy deadline delay, save it for the next game.
13. If you're behind schedule, determine which components of the game are important so you can cut off whatever that would be nice to have, but is not necessary.
14. If you're at a point where everyone else has quit and it looks like the project will not be completed as designed, use this as an opportunity to strengthen your "finishing skill." Scale the game way, way back, even to the point that it is no longer anything like the original concept if need be, so that you can finish it.
15. The last 10% of a game, the polishing part, always takes longer than you expect, but can be extremely satisfying and is usually where the game starts really feeling like a game, instead of just some project.

Here's what I've learned that we should apply to our own game development efforts:

• We aren't to the level of Blizzard or other triple-A game studios that say "It'll be ready when it is ready." We should probably get a deadline going, and make it public. This will give us a goal to work toward, and will give us the ability to determine what we should implement for the current game and what we should throw out or save for the next game. Making it public will make us feel pressure to complete it that we normally do not feel otherwise.
• We should probably have a written spec. Those are always good.
• Even if a good portion of game development might not be fun, we should try to maximize the amount of fun as possible, even if it is at the expense of a complete written spec or solid unit tests.
• Progress, not perfection.

To keep alive or not to keep alive

Networks are what make computers cool to me. Without a network a computer is like a car without wheels (perhaps not that bad but close). Ever since I wrote my first dumb networking code it still blows my mind that I can send data from one computer to another. One thing I have learned over my short programming career is that writing good networking code turns out to be hard. Operations on the local computer can and do fail, but for the most part it is not to hard to check for the error and do something about it. Networks, on the on other hand, tend to be very asynchronous and can fail in all kinds of fun ways.

The Internet, as I understand it, is based on the IP protocol. The IP protocol is based on the idea of best effort delivery, which has proven to be a powerful idea. It also means that about anything can happen and the endpoints of the network will have no idea. In the case of TCP one end of the connection can tell the other if it is going to close the connection. This happens if the process owning the connection is killed or the computer is turned off in a nice way. The case of the one computer dies in a flame of glory, or the connection breaks (someone pulls the Ethernet cable out to use in there laptop) does not let the other end know what happened. TCP is just a sudo connection after all.

Enter the keepalive. The idea is simple. Send some TCP packets over the connection and make sure a response is returned in a reasonable amount of time. The question is what level of the networking stack should this happen on? Currently, I have done this in applications level. In the protocols I make, I will have a ping/pong message that I send so both sides know that connection is up. It turns out that it can also be done in the tcp level. It seems most OS have the ability to send a TCP packet with no data, but the response flag is set to true. In Linux there are a number of setting that tell the interval to test the connection on, the number of times to retry, and the amount of time between retries.

I have yet to test this out compared to the applications level stuff I have done, but I have high hopes. The applications level ping/pong does provide more feed back about what is happening and it is up to the application what to do about it. The ping/pong approach has a number of issues. The first is it makes the application code more complex. The application not only has to handle a the case of the connection closing, it has to have timer and other code to decide the connection is dead and should be aborted. The second and perhaps most important is, if the application is sending a lot of data the ping/pong message might not be sent for the timeout value. That means one side the connection might decide the connection is dead just because it was to busy. Now this "problem" happens if you just depend on the ping/pong to reset your timers, so I think it can be worked around. But it is still messy, in the code and the protocol. Then what if you not are not making your binary protocol?

To end the rant if the OS can be set to keep the connection alive, and it works well I say let it. Now all this it assuming a long lived TCP connection. UDP has its own issues, which I have yet to try and work with. I think UDP puts it back in the application level to manage the connection.

(Update)

After more thought I think the most flexible design is to use a ping/pong in the applications level. Even if it is more work to code. It provide more portability and test more issues. Now if you are just writing a brunch of server to server code with something like Google Go it might work out to have the OS handle it (assuming Linux).

Remember this ad?

I sure do! I remember first watching it and then getting the surprise twist at the end. Good times, seven years ago in 2003. Too bad they ruin that effect by telling you what it is in the title, but still a class act, even if ultimately it doesn't convey anything of useful information.

The future of gaming: Best thing ever, or Brave New World scary?

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/

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:

• 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!

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?