Category Archives: Guest Post

Building a Game (Guest Post)

This week I am doing something a bit different.  I asked the winner of the XNA contest that I held to promote my Pluralsight course on game programming with XNA to write up a guest post about his experience making the game.

joshuaburchatipad thumb Building a Game (Guest Post)Joshua Burchat was the first place winner of an iPad, and he graciously agreed to do a write up of his experience.

So congratulations again and thanks you Joshua.

Here is Joshua’s post:

After winning the XNA contest John asked me to write a guest post about my experiences with the course and developing the game. So here it goes.

My name is Joshua Burchat and I’m from Oakville Ontario. I work as a developer designing and supporting business applications to support reporting within warehouse operations. My language of choice is C# but I enjoy trying other languages and technologies.

What appears to be a daunting task

When I saw John’s post I was instantly excited about the course. The only experience I have making games was doing a small Cocoa2d chess game app. I had yet to do anything with animations and moving sprites. Writing code for a game seemed like a daunting task. I decided that I needed a new project to work on, and this would be a challenging and worthwhile task.

After starting the course, building a game seemed so much more simplistic from a coding perspective than I originally thought. John has a great layout to the course. Upon completion, you end up with a fully functioning basic space shooter game.

Doing something a little different

When doing any sort of tutorial I tend to want to write a different application than the example being presented. I do this to enjoy writing the application because it’s one of my choosing, and to run into different scenarios which need to be solved. I use a similar practice when learning a new language; except I usually pick a program I have already written and port it.

Wanting to do something different, I decided to go with a side scrolling platformer. The plan was to make it like Mario but with punches, a health bar and an energy bar. The course got me started with how to display graphics and create boundaries for game entities in a very simple and reusable way. The course also teaches you how to implement sounds and game states (pause, next level etc.). There were quite a few things that you need to tweak to make a more advanced game. However the structure you are given from the course is very extensible.

One of the things that I needed to add to the game that was not in the course is the concept of gravity. The player, as well as some of the enemies needed to be able to jump and fall. Entities needed to be able to transition to different animations as well as be prevented from doing certain actions while the animation has yet to finish. I ended up using a similar method that John used for the game states; I made sprite states. When a sprite had a specific state it would determine what the sprite is currently doing and what it could do next.

The current state would have an update method that the sprite would call from its update method in the game loop. The state was responsible for setting the animation for the sprite and whether or not the state should change. For example, when the up arrow was pressed the standing and walking action would lead to the jumping action for the player sprite. Enemy sprites had actions that they used to make them attack and move around.

Here is an example of the player sprites states:

clip image001 thumb Building a Game (Guest Post)

Once implementing the ability for sprites to change state, I needed to make use of them. I had five types of sprites in the game:

Player: Controlled by user input. The player sprite has an energy level that is used to preform jumps and punches. The energy recharges over time. This sprite also has health, the player has to restart the level when the health hits zero or if it falls off a ledge.

Enemy: Controlled by its surrounding. If they hit the edge of a platform, turn around. If it hits the player, change the player state to ‘stunned’ and takes some of the players health away.

Terrain: Represents the bounds for that prevent the player and enemies to go past.

Background: Elements that do not have any effect on the other sprite types, and are simply for visual effects. Some background effects move, such as clouds or snow.

Item: Created from an enemy sprite when it is killed. Adjusts the players stats such as health or energy.

Here is a video of the game play:

Lessons Learned

After completing the course you will definitely be able to make a basic game and in time and with a good amount of effort you should be able to make an excellent game. There are a few things besides coding that go along with game design that I find to be the hardest aspect of the craft. These are things that I will need to improve in my game.

Physics/Feel: The way entities interact, timing, controls. The physics of the game help to allow the user to feel the game. If the characters move too slow or don’t jump in a logical way then the user feels it and the game becomes unappealing.

Story: Games should have a story, it can be simple or complicated but it needs to exist. While making this game I did not really start off with a story, I just wanted to learn the programming aspect. Now that I have learned enough to make a more robust game, the next one will definitely have a story.

Graphics: I have no skill at creating graphics myself; I needed a bit of help from my girlfriend to make some decent sprites. Graphics are hard; the game needs to have a good style that helps keep the user’s attention and make the experience more enjoyable. When I say good graphics I don’t necessarily mean high end rendered images, I simply mean they need to be appealing and click with your game. A good example of this is Minecraft, it looks silly but it is very fun to play and has a large following. It is also important to keep in mind what John states in the course, don’t worry about the graphics when learning to make a game. At the beginning of this game’s development I used boxes for sprites, it looked silly but it got me through the tunnel.

Since working on this project, I have recommended this course to a few of my fellow developers at work. Not because they enjoy video games but because I believe making a game helps strengthen your OO skills. I was surprised at how bad I was at doing something that consists purely of writing objects; it really put my skills to the test.

I ended up rewriting some the application a few times before I had my base designed in a manageable way. I am a strong believer in writing a program more than once, learning from the mistakes of the first pass through and coming out with something more refined. I would recommend this course; it is definitely worth your two hundred free minutes of PluralSight if you have not signed up yet.

Where to next

Now that I have made a platformer game I would like to try something different. I am going to try to make an adventure RPG, attempting a classic Zelda feel perhaps. Another thing I am going to attempt is to port the game over to ISO and Andriod either manually or using mono.

Making games is something that I could see taking whole bunch of effort and failures to get right. I want to try various types of games so that one day I can make one that I consider distributable to the public. I am not releasing this game on any application market, it is still a half cooked and there are quite a few improvements I would need to make.

I am glad that I had entered this contest, and I believe that it was a building block for a great hobby and maybe one day a career. Thanks John for this fun project, many a nights were spent with key clatters. I hope everyone else had a great time making their games as well.

Guest Post: The Cross-Browser Compatibility Myth

This post is a special guest post from my wife, Heather Sonmez, who is an expert on the subject of blackbox automated tests and designing frameworks for them.  She has designed successful automation frameworks for several companies.  She deals with software automation and framework design issues on a daily basis, so I thought she might be able to offer some good insight on the topic.

John asked me to write a post based on my experience with writing automated tests.  I’ve been working as a QA Automation Engineer for the past three and a half years. During this time I have had the opportunity to work with Ruby/Watir, C#/Watin, and Java/Selenium RC. In thinking on a topic, I decided that there’s no time like the present to talk about what I’m presently facing, and would like to share some insight straight from the trench I currently find myself in today:

Automation tools that claim to support multiple browsers are LYING

Currently I am in the process of getting 400 automated tests that run in Firefox to run in Internet Explorer and Chrome. While the tests are using Selenium RC, a tool that claims to work on all three browser platforms, in actuality, many tests are failing and not for good reasons (bugs).

Here’s the rundown on what these overly-ambitious tools aren’t telling you:

  • Xpath in Browser A isn’t always supported in Browser B
  • The Dom in Browser A may vary from the Dom in Browser B
  • Browser B may have built-in security settings that interfere with testing
  • Bugs in the automation tool itself may cause issues in specific browsers
The XPath Issue

When it comes to XPath, I fully expected that any given expression was either valid or invalid. But it didn’t take more than one test run in Internet Explorer to suddenly find myself with tests that claimed certain elements didn’t exist. While Firefox accepted and successfully returned my element using the provided expression, IE claimed the expression itself was invalid. In this particular instance I discovered an issue with Selenium stripping off the end of my xpath statement, thus making it invalid.

But ultimately, whether it’s the browser or the tool doesn’t matter because the same expression is not working unequivocably in both browsers.

The Dom Issue

The next problem I immediately came across was the problem of Dom differences between browsers. In this particular case I had an element that occurred one time in Firefox but twice in IE. My test, expecting one instance of the element, failed. While I can’t tell you why this discrepancy exists (currently under investigation by some client-side engineers), I have a fair degree of confidence in saying this won’t be the last time I come across this issue.

In the quest to support many different browsers, it only follows that one is going to come across conditional browser logic, especially if a company is striving to support multiple browser versions (IE 6, 7, 8, 9). If a developer has to occasionally write browser-specific condition statements, it makes sense that we’d have to do the same to test specific browsers.

The Security Issue

If it seems that I’m picking on IE, it’s only because I can’t get very far in running our tests in Chrome. Chrome has special security settings that cause a Selenium exception if your test changes domains mid-run. This can easily be solved by passing a parameter to Chrome which will disable this security feature when the test runs, the trick is figuring out when/where/how to pass that parameter.

The Bug in the Tool Issue

Finally, the last obstacle I’ve come across in multi-browser testing: the tool itself. Any tool, regardless of how fabulous it is, is going to have bugs. Selenium RC has an issue where its select method (responsible for selecting a value in a dropdown menu) doesn’t trigger affiliated event handlers- in Internet Explorer. To work around this, one can manually call the event handler using Selenium’s runscript() but you will lose some degree of testing confidence in doing so (how do you know the event is really firing in response to a particular user action if you’re manually forcing it in automation?)

Another issue exists around multiple browser windows; if you need more than one open for your test, Selenium is unable to select the second window you open- another outstanding IE issue that has not been resolved.


In all fairness, some of these issues have more to do with the browsers themselves than with the automation tool. However, that makes it even more important to realize that when an automation tool says it supports multiple browsers, it’s not without some creativity, troubleshooting, legwork, and maintenance.

Knowing these kinds of issues exist is important in order to decide if and how much browser compatibility testing you want to automate. It’s definitely something to realize before deciding on a tool just because the tool claims to support other browsers.

Just as there is no silver bullet for writing a web application that works in every browser imaginable, there is no silver bullet for automation either.