Geeks With Blogs

News

Series

Add to Technorati Favorites


An Archived Managed World This blog has moved to http://www.managed-world.com/blog

[Crosspost from Managed World]

After using a homegrown logging solution at work, I forget just how nice and easy log4net is to use. It really makes me want to encourage other developers at work to use it. It took only a matter of minutes to hook it up into Tanks and get the major components logging. So, that's one thing to mark off the list.

Although I wasn't originally planning on doing it this weekend, I had noticed that version 1.0 of Irrlicht was finally released. So I took the opportunity to upgrade Irrlicht to 1.0 in Tanks since I am still in the early phases of development. With the functionality that I was using there were no breaking changes so the upgrade went flawlessly. One thing that is an annoyance for me is that though there are "interfaces" in Irrlicht (like IVideoManager), they are _not_ actually interfaces. They are simply classes that have an "I" in front of them. Bad developers, bad developers! I fully expect as a developer that if I'm using a class prepended with an "I" that it is an actual interface. Why am I so annoyed at this? Because it means that I can't mock my TanksApplication class like I was wanting to because they aren't actually interfaces. I could write my own interfaces that are _actually_ interfaces around the Irrlicht "interfaces", but I don't think it's particularly worth it at this point.

I went ahead and brought over the CommandProcessor, sort of. In the prior life of Tanks (the Boom! game engine) I had seperated the notion of Commands from Events. While this may have been good in theory, after developing the game more I felt that it was unclear where the seperation of the two really were. I had more internal debates with myself over "Is this a command or an event?" than I wish to admit. Not only that, but when you compared the CommandProcessor class with the EventProcessor class it was pretty clear that they were nearly identical in functionality. Due to these issues, I have decided to go forward with just Events this time around (I called them GameEvents this time to better illustrate the difference between these GameEvents and events built in to the .NET Framework via the event keyword).

There was one other design change that I decided to make this time around. In the past I have used a more Java-like Listener pattern using interfaces and have avoided delegates and events for the most part. I can't really explain why I've done this in the past as I'm a .NET guy through and through. I suppose one thing I like about the interface-based listener approach is the ability to group methods together (like having an IKeyboardHandler that contains OnKeyDown, OnKeyPress, and OnKeyUp within the same interface rather than three seperate delegates). However, I decided to mix things up this time and do it "the .NET way" using delegates and events. One thing that I do love about using delegates and events is that so far there is less code required to wire it up and get it running. For listening to GameEvents, I am most definitely appreciating the capabilities of multicast delegates so far. So, with all that said, the GameEventProcessor class is now implemented and working.

I have gone ahead and wired up some unit tests to the StateManager and GameEventProcessor class like I should have done in the first place (bad Jason!). The code coverage right now is _far_ from stellar, sitting at a depressing 19% coverage. It's better than nothing I suppose, but still not as high as I would like to see it. At times it is definitely a challenge unit testing game code as it requires you to become more familiar with mocking and creating facades around your device-specific code. Oh, that reminds me. I went ahead and upgraded my unit tests to use NMock2 (I was using the original NMock before). Man, NMock2 is nice. I like how it reads. It reads so well that you can nearly read what your unit tests are doing in English. FOr example, here is a following mock expectation that I am performing in NMock2: "Expect.Once.On(newGameState).Method("OnKeyPress").With(new EqualMatcher(ConsoleKey.Enter), new EqualMatcher(false), new EqualMatcher(false));". Most people that I've talked to either love it or hate it. I just so happen to be grouped in the former :).

I haven't started on the Console yet. After I publish this post, that is my next stop. I'm currently thinking that once the Console is finished I'll move on to stubbing out the Model/View/Controller infrastructure that the functionality in my game will be built on. So, until next time, I'll see you around :).

Posted on Sunday, April 30, 2006 12:52 AM Game Development | Back to top


Comments on this post: Tanks - Update 1

No comments posted yet.
Your comment:
 (will show your gravatar)


Copyright © Jason Olson | Powered by: GeeksWithBlogs.net