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 :).
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 :).
This kind of bit me in the bud for a while here at home, so I thought I would throw this out in case any others are having the same problem. The symptom was even though I had a setup method decorded with the "SetUp" NUnit attribute, the method wasn't being executed by TestDriven.NET. Luckily, I don't believe this is an issue with TestDriven.NET as it as an unfortunate side effect with the new C# class templates in VS2005. By default, when you create a new class in VS2005 (at least for me), the class is simply declared as "class MyClass" rather than "public class MyClass". That is what is causing the failure. Once you change the scope of the class to be public, TestDriven.NET will now start running the Setup method as expected. When you think about it the behavior makes sense. But it is frustrating nonetheless :).
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 :).
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 :).
You know what? I realized something over the last several weeks and it sort of worries me. Surprisingly enough, this actually has nothing to do with Rory whatsoever. I'm sure that's a first, but a guarantee I cannot give for I have a feeling it is not the case nor the knot. Or is it, perhaps maybe it is or to be hither? Yay to be to yay, just mine for mine just. A rhino's nose hath bloweth but to thine growth I stayeth true. For gredd? Nay! For love! Or happiness I suppose. Or perhaps just fun. Yeah, for fun. 'Scuse me!....................................... Okay, nevermind all that. I just thought I would let you all know that I'm finally returning to happy programmer land (from hereon out to be known as The Land of Great Joy). I've been away, it's true. That is no lie. But don't fret for I have returned, my friends. And I shall spread my seed of wonder all 'cross the land and proclaim this land to be free. Free of office politics, free of social awkwardness, free of fear and remorse. Our harvest shall be bountiful and neverending. For this journey is a journey that I look forward to with great anticipation and shall forever cherish. To make a long story short, I have gotten back into game programming and am planning on picking up the articles that I left off unfinished around, well, FOREVER ago. For once, I'm determined to finish one programming project of mine. I will most likely be using this blog more as a journal for that game development like I was a while ago. I will put everything into the Game Development category, so feel free to ignore if you wish (warning: ignore at your own peril as I know where you all live and will track you down and punish you (unless you enjoy that kind of thing, in which case I will most likely just ignore you))). Now, until I change my mind yet again, and let you all down again, and just decide to be selfish and do yet another thing, again...
Benjamin Nitschke made an announcement today that the English versions of the video tutorials for Rocket Commander have now been released on the Coding4Fun website over at MSDN. The website says each video tutorial is 40 minutes. There are ten tutorials, so we are looking at possibly 400 minutes of video tutorials on game programming if the numbers are correct :). So, well, take a day off of work (or two) and enjoy the tutorials :).
I've been waiting for this since the original versions were released on the German Coding4Fun website. I had sent an email to Benjamin and he told me that there were English versions being done so it's been a waiting game for me.
Great job, Benjamin!! I look forward to watching these and seeing it all done. Keep up the great work :).
I fear that with this latest news from Apple, I may not be able to resist the temptation to buy a Mac anymore. I've felt for a while that Apple creates products with a certain "sexy-ness" factor to them. The only preventing factor to date for me when thinking about purchasing a Mac has been that all my development at work takes place on a solely Windows platform.
Well, it appears that this is no longer an issue. Oh great. I guess I should start saving up now for the money I'm going to blow :).
|