Tanks

Tanks - Update 7

Jason Olson — Wed, 17 May 2006 11:05:00 GMT

After talking last night about integrating a collaboration pattern I was working on at work with a coworker, I have decided to go a different route. I stubbed out the framework tonight for a Microkernel that will drive the game engine. The current version as it exists tonight is very simplistic. The only current functionality in this Microkernel is the ability to add a Task for per-frame processing.

This new Microkernel should help decouple my system a bit more and make it easier to enhance. For instance, instead of your "usual" game loop where you might actually see direct calls to game objects to update themselves, in this system you basically see one call to the TaskMaster within the Microkernel instead. So, if I have a GameStateManager and GraphicsDriver that both need to be updated once per frame, they would register tasks with the Microkernel. This means that when I am "boot-strapping" the game, I essentially am hooking up the components into the TaskMaster. In the case above, you would see something like "taskMaster.Attach(new CallbackTask(gameStateManager.OnUpdate));" and "taskMaster.Attach(new CallbackTask(graphicsDriver.OnUpdate));".

Where this tasking system really starts to shine is when you start doing animations. For instance, if I am implementing a 3-second respawn feature into my game, I can create a special task like "new WaitTask(TimeSpan.FromSeconds(3));" and then attach a SpawnTask as a child task to the WaitTask (so that it is automatically called when the wait time has elapsed). That's just one minor example. There's a whole slew of other examples if we go into the GUI world.

Eventually this TaskMaster will grow and probably have the ability to do "time sharing". I'm thinking of adding that feature in the future so that I can time slice the Tank AI since the AI will be implemented in scripts by the end user (yes, you programmers). This will ensure that a Tank doesn't hog too much time when updating itself and should ensure that every tank is on a level playing field when it comes to processing time.

Tomorrow I will probably start on a MessageProcessor to the Microkernel that will enable cross-sub-system communication within the engine. After that, the Microkernel will probably be done for a while. I might eventually expand the Microkernel to support a virtual file system as well for game files, but I don't want to put the cart in front of the horse here. The more I think about, the more I feel that this is almost like implementing a mini-OS in software that is specialized to running a game. Pretty fun stuff.

There are some other things I've been thinking about though. I've been thinking about introducing a service layer that would host services that would be stateful and would basically drive the underlying functionality in the engine. You might see a GraphicsService, a ScriptingService, a PersistenceService, a GameObjectService, etc. Then the various Message handlers would communicate with a ServiceLocator to get references to the different services in order to do their deeds. This pattern is an adaptation of the pattern I've said that I'm working on at work so hopefully being inspired by that won't take too long :). The ServiceLocator does seem to be quite Spring'ish after a while, but that should be fine. Heck, if I eventually want to power it off of Castle or Spring.NET I could do so if I choose to.

Anyways, off to bed for the night. As usual, I'll keep you updated on the latest happenings in the development of Tanks :). 'Til thenz, my friendz.

[Crosspost from Managed World]

Tanks - Update 6

Jason Olson — Tue, 16 May 2006 09:07:00 GMT

In light of my recent purchase of a 360, I know that many of you out there thought that I would drop off the face of the planet for a while. Well, too bad, I'm back (well, still here actually). I've asked my wife to help me with my nearly-half-year-just-bought-a-360-and-don't-want-to-drop-off-the-face-of-the-planet resolution. This resolution is that I won't play the 360 during the week (or at least limit to one night or two), and that weekends are free game (no pun intended, of course). This should help me at least get _some_ work done on my other hobbies (like this game). So now that you know that, it's time for an update :).

I've decided to make one fairly major change. My first stab at this game will actually be in 2d. Now before all of you start yelling, there is a good reason for this. Frankly, I want to get to the game programming stuff that interests me: game playbacks, saved games, AI, programmable bots using a scripting language like Boo, etc. The quickest way to get there is to "prototype" the game using 2d. My goal is to code the game in such a way that I can "upgrade" the game to 3d at a later date.

In that vein, I have downloaded SDL.NET and am changing the application framework as it exists right now to use that. My hope is that I can finish this conversion by tomorrow evening and then be on my way again. That is at least my short-term goal for tonight and tomorrow night.

After that, I will be integrating a collaboration/eventing pattern that a coworker started putting together at work. I have started working on it myself and helping move the development of it forward and I am really loving it. It is not far from the event-driven pattern I was using in the Boom! engine before. My goal is to have that integrated and unit tested by sometime early next week. I would shoot for earlier (because it won't be too much work) but I have some prior engagements that will keep me busy several nights this week/weekend.

Anyways, back to work :).

[Crosspost from Managed World]

Tanks - Update 5

Jason Olson — Wed, 03 May 2006 11:57:00 GMT

[Crosspost from Managed World]

Great. If it wasn't bad enough being sick still, my internet connection just had to be down all evening. Luckily, it _just_ came back up so I can actually post this update. So let's discuss the progress on Tanks, shall we?

Most of my "free time" I've had lately (which hasn't been much with me being sick (since my body proclaimed several hours at a time to be "nappy time")) I've spent writing the unit tests around the last couple of classes I ported over from my previous project. The process has made me appreciate the work Microsoft has put into Visual Studio 2005. Having the integrated Code Coverage reports is pretty nice. I know you can get that with NCover/NCoverExplorer, it's just nice to have it "out of the box". You add to that all the amazing work that Jamie Cansdale has put into the TestDriven.NET add-in and it makes for a wonderful environment to be writing unit tests in :). I don't know why, but I get a certain thrill out of writing some unit tests and then seeing my code coverage increase.

The ConsoleModel class is finally wrapped up in unit tests and tucked in to bed for the night. What kind of surprised me is that by writing the unit tests I wanted to write against the ConsoleModel class, it just so happened that I got full coverage on my ConsoleEntryLine class as well (which is used by the ConsoleModel class). Killing two birds with one stone is nice sometimes :). For my Tanks.exe, I'm up to 67% test coverage. That number is a little misleading though as I have all my unit tests within the executable itself. If I don't count my "Test" namespace and only count the core "ManagedWorld.Tanks" namespace, I'm actually sitting around 51% test coverage (right around where I thought I would be at this time).

The problem I have right now is the rest of the code currently in the code base (or about to join the code base), is all device specific around the IrrlichtDevice. I don't really want to unit test down to that level as the ROI would start to decline dramatically with the time I would have to invest simply writing the unit tests. However, that doesn't mean I don't want it tested. I'm thinking that sooner or later I'll work on introducing a script-based testing framework for the application. Then I'll write a harness that can be run from NUnit. My hope currently is that the NullDriver for the IrrlichtDevice will still be fully functional under the hood but simply won't be driving the graphics card. If that is the case, then I should be able to write this script-based testing framework (not that it won't be without it's hardships). Then I can use the scripts as more of an "acceptance tests" system that will help me test from the UI level. Of course, my hope is that if I can do that via the NUnit custom harness, then it will be able to be reflected in my code coverage reports alongside of all my unit tests. I still feel like this is quite a ways into the future from now though (meaning, I won't worry about it until I cross that bridge since there's no shortage of tasks to be done in the meantime).

I have a confession though: I'm trying to not get too granular with my unit testing. I know some people have strong opinions on what level of granularity to unit test. For me, it just seems "wrong" to have one separate unit test per method in a class. I can't really put my thumb on why I feel that way yet. But having one test fixture per class, and one unit test per method (or I've seen even smaller in the past (meaning multiple unit tests per method)) just seems like it is missing the boat. By the time you get this detailed, it seems like you begin testing the functionality of the .NET Framework rather than focusing on the behavior of your class under test.

I've even started to think that maybe focusing on testing one class at a time might be too granular as well, but the jury's still out on that one :). If you can test all the nooks and crannies of your class at the module level, than why not do so as the unit tests can become much more clear to read (since they start asserting behaviors of the module as a whole). Enough of my ruminations for one post. I'm still largely a unit testing newbie, so I won't bore you with my not-yet-mature stream of consciousness.

So, what next? I believe I'll crank out the ConsoleController and test that. Once that is finished, it is on to the ConsoleView. I'm still not sure how I'm going to test that (if I'm going to test it at all). Once that is done, however, the Model/View/Controller for the Console will be finished and will be ready to integrate into the game. Maybe then I can "call it good" for this stage of the game and get started on replacing those articles that I never finished a LONG TIME AGO (although _not_ in a galaxy far far away (contrary to popular belief)).

Catch you on the flip side, space men :P. (I was going to say "filthy pig dogs" but I thought that some of you might get offended if you don't know where it comes from).

Tanks - Update 4

Jason Olson — Tue, 02 May 2006 11:35:00 GMT

[Crosspost from Managed World]

Late night inspiration! Sometimes I really love these kinds of moments. This one came to me as I was trying to get to sleep (and apparently my brain didn't want to let the problem go :)). One of the problems I discussed in an earlier update was that, for some reason, the Irrlicht .NET wrapper decided to implement all "interfaces" (ISceneManager, etc.) as classes, some of them not even containing default constructors. The heart burn this caused is that I'm not able to Mock and Unit Test my master TanksApplication class unless I go through all the trouble of taking all the Irrlicht "interfaces" and wrapping up my own interface-based facades around them. For this type of project, I didn't really want to go through all that hassle.

I guess something my brain saw during all my effort of getting Blender-exported .x files to work came to the forefront. Basically, I remember seeing when starting up the Irrlicht MeshViewer application that Irrlicht has actually implemented a "NullDriver" along with the other drivers (like Direct3D9, OpenGL, etc.). I tried it out in my application and it's pretty cool. It basically is a fully functional IrrlichtDevice but doesn't drive the graphics card. This will enable me to create a mock object that I can pass in and drive the TanksApplication with (by having the mock class be driven by the NullDriver and returning the actual Irrlicht classes rather than mocks themselves).

The "so-and-so" aspect of this is it's not necessarily a "true" mock object, but heck, it will work so that makes me happy right there. The other unfortunate side effect is that the unit tests in question will be tied to Irrlicht as well but that should be alright as making this application graphics-platform-independent is out of scope :).

I really get a kick out of some of these "a ha" moments :).

In other news, I have finished the unit tests around the GameEventParser class. All in all, I have increased code coverage from a dismal and depressing 15% to around 35% (still quite low, but a lot better than 15%). By the time I wrap the Console class up in unit tests (and the TanksApplication class after my late night realization above), I should be sitting above 50% which will put my mind more at ease with the state of the code base.

Now I'm back to trying to get to sleep (if my mind lets me), so I will chat with all y'all l8r (had to get at least one hackish expression in there ::grins::)

Peace out!

Tanks - Update 3

Jason Olson — Tue, 02 May 2006 08:53:00 GMT

[Crosspost from Managed World]

I haven't been able to do much lately because I've been fighting off a cold (to the point where I've had to take time off from work (which I _hate_ doing)).

There hasn't been much progress writing code as I've been busy playing around with Blender. I've been working through tutorials and such to get up to speed with it (so that I can at least put _some_ of my own models in the game (no matter how crappy they may be)). The verdict so far? I like it. When working through tutorials, it really isn't that difficult to learn how to use and is a pretty powerful tool (let alone the fact that it is _free_ which I always love :)).

It hasn't been without its problems though. Mainly, .x file export is borked for me. I have tried using Blender 241 with Ben Omari's Exporter for 241, I've tried rolling back to 237 and using Mindbender's export script, I've messed with every exporter option in the book, and still no luck :(. I've used practically every tip and trick that I can find on the web dealing with this. You see, the problem isn't so much with the .x file, it is when I try to use the .x file in Irrlicht.

The problem is that the model is oriented wrong. When I load it in the DirectX Mesh Viewer, it looks exactly like it does in Blender. However, when I load it up in Irrlicht the orientation is all FUBAR. I understand the difference between the two coordinate systems (as Blender uses a different coordinate system than DirectX and Irrlicht do), and the exporters I use have options to "transform" the model. The steps I still have left to try: 1) install python 2.4 and make sure my PythonPath variable is set (perhaps parts of the export script aren't functional in Blender because of this), 2) rollback from Irrlicht 1.0 to the version I was using before, and 3) trying to fix the exporter script myself (after all, it is just Python code). For now though, I'm putting it on the back burner as I have many other things to do.

So, my foray into modeling, while fun, did contain its own share of hardships. Well it's not like I don't have enough code to write anyways, so I'll just go back to doing what I know I can do :).

I still need to wire up the unit tests for the GameEventParser (basically, "parses" GameEvents from a plain text string (serialization/deserialization)), and the ConsoleModel/ConsoleEntryLine. Usually I would write the unit tests before or with the functionality I'm writing but these classes were ports from a prior project, hence the lack of unit tests. And I'm determined to fix that this time around (you know what I just realized? I certainly use the phrase "this time around" a lot; man, time to get some more phrases to use :P).

I'll probably start coding up the unit tests tonight but won't finish them until tomorrow night or Wednesday evening. Because I have to work during the week (aka "A Day Job"), I probably won't get much done in the evenings. I'm planning that most time spent working on this project will likely be on the weekends. In other words, don't expect too many Tanks updates during the week.

Until next time, remember, don't wait up for me and I'll see you on the flip side :).

Tanks - Update 2

Jason Olson — Sun, 30 Apr 2006 11:21:00 GMT

[Crosspost from Managed World]

I have now ported over most of the Console functionality from Boom!. I still haven't ported over the ConsoleRenderer yet, so I'll just tackle that tomorrow hopefully. As a little background, Boom! was originally written in 1.1, so I've been pleasantly surprised with how much code I've been able to remove simply because I can use Generics now. The downside? We're not using 2.0 at work yet so it's torture everytime I need a strongly-typed dictionary or list during my day job. I'm starting to realize just how spoiled I might be by being able to choose exactly what technology I want to use on my private projects :).

The current thought that I am having regarding the Console functionality is that I'll implement it using the MVC pattern (Model/View/Controller). The MVC pattern has been floating around at the back of my mind as of late. For the implementation, I'm contemplating introducing a GameContext object which will be the "context" for a GameState. Basically, the GameContext will contain the current Model, View, and Controller that the GameState is working with. Then I'll have the GameState actually have a stack of GameContexts which will enable pushing and popping of contexts. For example, if the user opens the Console a new ConsoleContext will be pushed onto the current GameState. Then when the Console is closed, it will pop itself off of the GameState.

There are some issues I have to work through on this one though: like the fact that I want the GameView to continue to render even if the Console is open (since the Console will only be taking up 1/3rd of the screen). Perhaps it is not the context in which I am pushing and popping, but it is just the GameControllers. If that is the case, there may not even be a need for a GameContext object (as it is just a glorified "wrapper" anyways). Even that idea I'm not entirely comfortable with though as I want to support both a List of GameControllers as well as a Stack. In the case of the Console object, I want to actually push the ConsoleController onto the stack to make sure that _it_ is receiving the current events. However, in the case of two controllers like a PlayerController and a ComputerController (for computer opponents), I want both of them receiving all events at the same time. So, perhaps both a Stack and a List are needed. Or perhaps I can get away with just one if I use an adaptation of a Composition-type pattern? Anyways, there is a lot to think through :).

Well, until then, I'm off to bed and I'll see all y'all on the flip side :). Maybe I'll have those pleasant software design dreams tonight :).

Tanks - Update 1

Jason Olson — Sun, 30 Apr 2006 05:52:00 GMT

[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 :).

Tanks - Engines and Source Files and Scripts, Oh My!

Jason Olson — Fri, 28 Apr 2006 11:33:00 GMT

[Crosspost from Managed World]

Now, for my first update. Let's get started shall we :).

This time around this project, I made one big change. Last time, the game was written in homegrown Managed DirectX code which required me to write a lot of the "engine" code that powered the game under the hood. To be able to focus on the game this time instead of the engine, I have decided to use an existing engine to power Tanks. Though this may come as a shock to some of you, I have decided to use the .NET wrapper for Irrlicht rather than write my own home grown engine on Managed DirectX.

Because of this decision, I will be emphasizing "Game Development With C#" rather than "Game Development With Managed DirectX". This decision will also allow me to not have to worry about the whole "Managed DirectX / XNA Framework" change until it has been released and baked out. Hopefully this will prevent me from having to write the articles over again because of an underlying technology change as big as this one might be. Another reason to do this is purely selfish I must admit. To be honest, I just want to get something done finally. I want to avoid this perpetually "starting again" cycle that I've gotten myself in by trying to learn something new every time something new is released :). Not only that, but I want to get to the point of diving into the "fun stuff" like integration of a scripting language, implementation of saved games and replay files, artificial intelligence programming, etc. You know, the fun stuff ;).

So, what progress have I made lately in this vein? Well, let's see....

Tonight I was able to port some of my Ruby-based automation scripts that I have for automatic generation of release notes based on svn commit comments and packaging of source code and binaries for release out onto this blog. Currently, the packager simply packages up the built binaries in one zip file and the source code and all necessities to build that source code in another zip file. I'm thinking that eventually I'll move to MSI install files for each. Until then, generated zip files will do the trick for me :).

I've also gotten a pseudo "tracer bullet" finished for the game. Basically, the GraphicsDriver, InputDriver, and StateManager are all working. I have created the various states that this game will have and have enabled the keyboard handling on each of them. You can now start the game and navigate through all the states using keys that show up on each screen. There is no art, per se, right now and all the "prompts" are just text written out to the screen using the default font in Irrlicht. The PlayState however does wire up the camera and adds a TestNode to the SceneManager to view.

My current train of thought is that the various states (implementing IState) will be responsible for hooking up the Model(s)/View(s)/Controller(s) that comprise that state. Basically, the state will facilitate a bootstrap process of sorts that will hook up all the individual components and then let them do their jobs. There are some issues that I will have to think through with this design. First of all, the current assumption is that only state is active at a time. Meaning, there is no pushing or popping of child states. That most likely will work for this game but it's not very scalable, in my opinion.

So here's the plan for tomorrow evening and this weekend (assuming I don't have to work):

- Going with my theme of not wanting to "reinvent the wheel" too much on this project, I won't be implementing a home grown logging component like I did on the last project. I figure I will just leverage Log4Net here and call it good.

- The CommandProcessor. I hope that I can largely just grab this component as it existed in the previous project and reuse it here as I won't be changing it that much. Once this is integrated (and unit tested), I can hopefully move on to wiring up a simple Console.

- The Console. One of the fun items, in my mind :). I hope to hook this up with a simple PrintCommand working. Now that I'm thinking about it more, I will probably take this opportunity to work on the State issue of not being able to "stack" states. It would cool if I could simply "push" this state on top of the current PlayState. Then again, maybe it is just the ConsoleController that I'm wanting to push. Hmm, that will be something to think about and dwell on.

The somewhat sad part is that once I get these three line items done, I will actually be further along than I was with the original articles I wrote. Because of that, I will probably take a break here to write the first set of articles and publish them. Hopefully then people will get their fix and get a better idea of what I'm trying to accomplish here.

Wow! I think that's one of the longest blog posts I've had in a while. I guess I sort of got out of rhythm with blogging as I started to take it in a direction that was not that personal and was very "detached". Well, I'm back, I guess (I don't know whether that is a good thing, or a bad thing. I guess I can say for sure that it is just "a thing" and call it a night :)).

So, until next time, feel free to shoot me an email and harass me as I consider this an opportunity to use you readers as "accountability partners" to help keep me on track this time :).

Tanks - An Introduction

Jason Olson — Fri, 28 Apr 2006 10:51:00 GMT

[Crosspost from Managed World]

Well, it's certainly been a while since I made one of these types of posts. But, it's important for me to get back on the wagon, so here we go :).

For those of us who are new here or haven't heard me talk much about Tanks, let me give you the quick five second intro to what it is. Tanks is a simple game that I'm developing that is single player (at least for now as I might dig into making it multiplayer in one of my future articles). Think of it as a 3d version of the Atari-classic Combat. I will be using this as a context in which to teach not only game programming, but also trying to promote software architecture and good design skills. To these ends, I will be writing a set of articles as I go along that will serve as tutorials in which to teach certain concepts.

Why am I doing this? Well, part of the reason is because I'm not content with the number of quality game programming resources that are out there. There are certainly a plethora of tutorials out there on game development. However, I, as a software developer, find them usually lacking in certain areas that I'm passionate about: like good software design, architecture, testability, etc. That's the niche I'm trying to fill here. I'm not only trying to teach you game development, but I'm trying to give you some guidance so that you can be happy with the end product and be proud to show off your code to everyone you know :).

From now on, I will be adding to my new 'Tanks' category with a journal of sorts on the progress of the game and some things that I'm learning. I hope this will make a good edition to the tutorials as well so people can go back and get better insight into the thinking process I went through at times when writing Tanks.

So, I hope you enjoy :).