Via Rory, I came across this interesting set of tutorials. They walk you through the process of designing and building a 2D game using Managed DirectX. The focus is on the construction of the game itself, rather than on the DirectX APIs, so I think it makes a great complement to the stuff I've been writing.
Thanks for link! Thanks for the complement too. You nailed exactly what I was going for. Your articles are excellent and I didn't think there is anything that anyone can really add to your articles when learning the API itself since they are pretty complete already. Keep up the great work :).
ReplyDeleteSame to you!
ReplyDeleteOf course, I'm reading Tom Miller's book right now, which (IMO) is an even better resource than my tutorials for the API stuff. My only consolation is that you can't Google his book's contents. :)
Tom's book is great. The only drawback is that you have to pay for it (which is okay with me since I definitely think he deserves the money since he wrote a great book). I think it is a good resource anyways since Tom Miller, from what I understand, is the guy that spearheaded the development of the managed libraries in the first place.
ReplyDeleteNot just spearheaded: he was the only developer. There were supporting characters, of course, but he was the guy who coded them. I had dinner with him the last time I was in Redmond.
ReplyDeleteThat's just incredible. He definitely did a great job......
ReplyDeleteJason and Craig, your articles are great. I'm learning a lot from them.
ReplyDeleteA little off-topic question: do you use an UML tool in your projects?
I am not a fan of UML, of patterns, or of many of the more formal methods of design. I think UML is vaguely useful for communicating class structures that you already have and need tell someone else about, but frankly, any equivalent set of boxes and lines would serve as well.
ReplyDeleteBasically, I find that UML emphasizes static aspects of code. By doing so, you wind up missing the important parts of how to build systems - the dynamic behaviors, the network traffic, and the interactions.
Yes, UML supports these concepts via sequence diagrams and interaction diagrams. However, these are rarely the focus of UML-based designs or tools, and they really don't offer much advantage over a good ol' flowchart.
All that said, I tend to work on distributed, scalable systems. There are lots of other types of programming in the world, and I can't speak to UML's applicability in those spaces. I also realize that I'm talking about UML as it tends to be used, and not as it would be used in a perfect world - but the high correlation between misguided OO purists cranking out nonfunctional or unmaintainable systems, and giant UML diagrams has left a bad taste in my mouth.
[sorry for such a long comment on your blog, Craig]
ReplyDeleteBy the sounds of it, I use UML more than Craig does. However, I strongly agree with Craig that "giant UML diagrams has left a bad taste in my mouth". I tend to use UML "as Sketch" (http://www.martinfowler.com/bliki/UmlAsSketch.html). I don't believe in the practice of using UML as blueprint or as programming language (at least in the systems I develop at work). However, UML as blueprint I think is vital in systems that can't have ANY defects (like Pacemaker software, Hospital software, etc). The problem I see is that if you use UML to document, in detail, how a system works, there is a greater chance that your documentation will become out of date. Anytime you are making your documentation harder to keep up to date, you are doing something wrong.
I am also, unlike Craig, a BIG fan of patterns. Patterns are a beautiful thing. They give you a given architecture that can be used for problems that have already been solved. I think perhaps 80% of the time when developing software, the "problem" has already been solved by someone else out there. Why re-invent the wheel? Not only are patterns great for solved problems, they are also great for communication. When my development team gets together to talk about the architecture of a given system, it's great to be able to communicate at the architecture level (i.e. "Well, since we are basically just doing batch processing of messages here, let's use the Command pattern for our message handlers. But since the format of the input in the messages can change fairly readily, let's use the Strategy pattern to define our message content").
Oh, and for modeling, I use Visio 2003.
Thanks for your answers.
ReplyDeleteI only use UML for class diagrams. By other hand, I'm also a big fan of patterns. I've got GoF's book and I'm thinking of buying Fowler's book on Refactoring.
By other hand, what resources should I look about test driven development, extremme programming, patterns and refactoring? I have visited those I've found on Craig's posts, like www.agiledata.com and www.martinfowler.com. Is there another must-read resource?
Thanks in advance, and greetings from Spain.
I should admit to my near-total ignorance of patterns. I'll make a point to do some more investigation of the topic. As for resources, Kevin Jones had some recommendations in my blog comments here: http://staff.develop.com/candera/weblog2/CommentView.aspx?guid=b95b0aec-53fb-47f4-b918-a17d4452d0f7 But the main thing, I think, is just to jump in. With TDD, there's really no need to reach some critical stage of learning before starting: you will likely see the benefits almost immediately, and there's probably no harm done if you start without totally "getting" it.
ReplyDelete