I spoiled myself today. I received my annual bonus at work and I outright spoiled myself. Actually, for me, that would be an understatement. I splurged so much it isn't even funny. What did I do? I went out and bought a 4GB iPod Nano _and_ a PSP (and all sorts of accessories for both of them).
When I came home and unpacked my babies from their packaging, I came upon a realization: both of these devices are incredibly sexy. I don't mean they are sexy as in "cool". I mean they are "feel a tingling in your virtual geek loins" sexy. They give me the warm fuzzies, they truly do.
The iPod. Wow! I'm just going to come out and admit it. This was my first experience in an Apple store buying an Apple product. I'm speechless. Apple sure knows how to build products (and a store for that matter). It feels like every little detail about the iPod was meticulously designed, right down to the packaging itself. That's right, the packaging was some of the best designed packaging I've seen as well (no lie). I can certainly see why Apple fans are Apple fans. A quick game of word-association when looking at this sucker would instantly yield the word Elegance.
The PSP is pretty impressive also. It may not be quite as sexy and elegant as the iPod, but it still has its own vibe. When I powered the sucker on, my heart skipped a beat. The screen is so crisp and clear. The graphics in the games are incredible. I think the gamer within me is in love. I feel the coming wave of joy from many future gaming moments I will have with this device.
I just had to mention these things because of how utterly impressed I was with the design of these devices. Now, if you'll excuse me, I must ask your leave as I really wish to be spending time with my new babies (not that spending time with all of you is all that bad).
Go play with my new toys I must :).
What is up? Not much by the looks of it. I'm finally starting to go out and dig up the various game engines written in .NET that I can leverage in the project I'm revisiting (as I'm not really in the mood to reinvent a wheel that has already been re-invented like a hundred million billion times by various college students out there (here's a theory: I think there are more game engine projects out there than hamburgers McDonald's has sold in the entire history of their company)).
So, what did I find? Sadly, not really anything to write home about. I found several projects, they were just in several stages of disarray. Several of them even have had a good amount of effort spent on them in the past. Some of them even show some progress and potential if only they were still active. Let us review ladies and gent's.
---------------------
Axiom: practically dead from what I can tell (the source forge project's home page isn't even functional and there are no binary or source files available for download).
---------------------
Realm Forge: somewhat active. There hasn't been _any_ news on the main page in quite a while when I visited the site. On top of that, there is very little documentation of any redeemable quality. Sure, there is some auto-generated documentation on the API but actually usage documentation is several lacking. From what I saw on the wiki, there is but one "real" tutorial posted. The extent of the tutorial is a single C# source file where the "tutorial" is embedded in C# comments. Not exactly what I would call a "quality" tutorial.
Sure, I could go and figure it all out myself. I may even still do that. Just call me spoiled. After working with the numerous .NET libraries and products I have at work, I like to be using a product that is supported and can at least point me in the right direction when things go astray.
To be fair, I'm not entirely disappointed. Realm Forge is looking to put itself forward as "the entire package" and not just a pretty renderer. I think it has some potential in that regard too. It wraps up a bunch of different components in order to package itself as a complete game engine. I just think it has quite a bit of "maturing" to go through until it reaches that point.
----------------------
Haddd 3D: it looks pretty and looks like it has potential. The drawback for me? All tutorials and help docs that I could find were written in Spanish. I know that the code should be enough, but I'm on a sojourn to find the "complete package" (or as darn near as I can find to it) and would like to be helped along in the process. Once again, I know I'm a lazy bones so telling me so won't provoke me in the least bit.
----------------------
Maybe I've just been out of the loop for that long now (how depressing). The next ones on my list to investigate are Irrlicht and Purple#. I'm hoping they will be a little more promising than the ones investigated so far. Have any of you come across some good .NET-based game engines or 3d engines that you like using?
In the meantime, I think I'm just going to go dink around with Ogre3d in C++ for a while and see what kind of fun I can have. Ciao!
I'm in the process of cleaning up my office so I made a pass through my technical books to determine which ones to get rid of and which ones to keep. Boy am I just a little depressed now.
Not only is there a HUGE stack of books ready to be led off into Technical Book Heaven but I made the unfortunate mistake of adding up just how much money I spent on the whole collection of books. Well, I'm sad to report that I'm taking back just over $1300 worth of technical books. I suppose the good news is that I've realized that I don't spend nearly that much money on technical books anymore. Not only that, but the technical books I have been buying have actually been pretty darn good.
I think a lot of this has to do with the technical book addiction I went through when first getting up to speed with programming. I haven't been programming for that long. Four years ago or so, I started buying up technical books in mass doses to "play catch up". Well, I think I relatively catched up (as much as you can in technology that is) but at a severe cost to my pocket book. Geez, sometimes it feels like I would spend less money if I were a drug addict rather than a programmer.
I raise my glass (okay, can of Coke) in hopes that next time I do a purging it won't be nearly as depressing.
But you know what? Even if it is, that's the way it is. Why? Because that's how I roll. Yup, you heard me: that's how I roll. Got a problem with 'dat? I din't thank sooo!
Well, my hosting renewal came up again. I've decided that it is not worth the money to pay for any hosting of this site (Managed World) since I don't leverage it at all. With that in mind, I've decided to move back to solely using GWB (http://jolson.geekswithblogs.net). So, if you are hitting the RSS feed here on http://www.managed-world.com please change it back to http://jolson.geekswithblogs.net as I will be taking this site down in a month or so.
Sorry for the inconvenience. I will send out another warning when the time comes for the cutover.
(And yes, Chris, after being a consumer of the GWB feed for a while now, I have a distinctly *different* feeling about the whole "Signal/Noise Ratio" argument now so you can expect me to be a good citizen :D)
P.S. DAMN! After going back and reading that Signal/Noise Ratio post I feel like such a dick head. Boy has consuming the feed changed the whole face of how I feel. I want to delete that post so bad, but I guess I'll keep it around to remind myself of how much of an idiot I can be at times.
Okay, I really hope this is not a scam. Because if it is, well, it shouldn't be because, well, it's cool, and... stuff.
Thanks go to Chris Sells for linking to this video.
Well, I've decided to revisit an old project that I haven't worked on for a while. The project was a game called "Tanks!" that was going to be the basis for a set of articles on game development with Managed DirectX. I'm still doubtful that the articles will make a come back but I definitely want to revive the project, with a twist that is.
Instead of a flat out Tanks game, I'm going to make it more of a programming game. Think of Terrarium meets Robot Battle (or Mind Rover (choose one)) meets Combat. You will be able to create your own Tanks in .NET that will be run in the game itself. I've been wanting to explore this kind of idea for a while and I think this might server as an idea vehicle (no pun intended) for doing so.
The few of you that attended the talk I gave way back at the Portland Code Camp might remember me talking about the architecture of the engine. Well, that will _radically_ change now. I don't know if I've just matured (doubtful) or just have a fresh pair of eyes to look at the problem (more likely), but I've realized that the messaging-based architecture I was using was WAY overkill for the problem. When it comes to the saying "using the right tool for the right job" well, I was using a chainsaw to slice up cucumbers for a salad (and in my opinion it shows).
For the first version I will be ripping out the physics engine entirely (as I don't think it really helps with the gameplay itself). I will be ripping out the messaging infrastructure. This should not only make it less overkill, but it should make it more approachable for the less experienced programmer as well. It may even be that the first version has just manual controls to control the Tanks as well. So be it :).
Maybe this time I can bite off a significant less chunk and see it through to at least the first public release (which would be a drastic step up for me (those of you who know me, feel free to shake your head in enthusiastic agreement at this point)). This time around, more unit tests, more integration, more re-use/adoption rather than roll-your-own.
I think it should be a fun thing. Who knows, maybe I can follow it through to completion with at least programmer art (and I'm sure some of you wouldn't mind since a finished set of articles).
In an earlier post of mine, I linked to this article by Jim Shore on how building software is nothing like construction. This is a topic I've been thinking about a fair amount lately and I've come to a conclusion: I don't agree entirely with Jim. Here's one of the quotes that have been hanging around in my noodle as of late:
"
In the software world, there is no reason for us to follow the practices of an industry limited by Newtonian laws. We have no gravity. There is no inertia. Lines of code have no weight.
If we want to dig a metaphorical hole after pouring metaphorical concrete, there's nothing to stop us. If we want to flip the software upside down and build a foundation after we've built the building, we can do it. Our only limits are in are (sic) heads. Once we stop thinking that software development is like construction, we'll have one less limitation to struggle with.
"
While it is technically true that we, as software developers, are not governed by Newtonian laws, I think there is one statement where Jim's hammer misses the nail's head: "Our only limits are in are (sic) heads". This is where I disagree.
It is indeed true that we are not governed by physical, world-bound laws. However, that does not mean that we are not governed by any laws whatsoever. This is not a logical conclusion. There are most certainly laws that we are bound by depending upon the context in which we are developing within. It is just that the laws are software-bound instead of physics-bound. Sometimes these laws are relative (like trying to build a new Enterprise-level application in .NET and SQL Server at a company whose entire infrastructure is built upon Unix and Oracle). I'm sure sometimes there are software laws that are absolute as well. The only limits are not in our heads. There are very real-world limits that will scope and change a possible solution. To me, that is one of the key points behind using the right tool for the right job. If we didn't have these constraints, we could use any solution for any problem no matter what the context may be (which unfortunately, I have seen done before).
To me, the interesting piece of research would not be researching the fact that we are not bound by physical laws. I think the interesting research is finding out what laws we are bound by in the virtual world. Who is going to be the Descartes, Newton, or Einstein of computer software?
If you've been reading my blog for a while now, it's probably no secret to you that I'm a fan of Open Source Software. I enjoy the benefits of using many open source products like NUnit, NCover, NAnt, etc. At the same time, I also believe that you need to be careful when modifying code in an open source product for use within the enterprise. Why? Because there are several hidden costs associated with modifying OSS that are not realized by your average company or developer. For the sake of this post, I am making an assumption that the developers making the modifications are not involved with and contributing back to the open source production in question (as I have seen this happen before).
The first of these hidden costs is the maintenance cost. When modifying an open source product, you have to think of the long term impact to the company of the changes you are making. As soon as you modify the source, your upgrade path becomes a bit more complex. Usually when a new version of a product is released, you can install the new version, do some testing of your dependencies and call it good (granted, this is, at at times, a gross oversimplification of the process (especially when there are API changes in that upgrade)).
However, when a new version is released of an open source product that you have custom modified for your company, you now need to not only upgrade the code but also make sure that the changes you made before are brought over if necessary. If the change is small, this may be manageable. However, if the change is not trivial this can be a huge investment of development time (that most likely could be better spent elsewhere). What happens if there was a good amount of refactoring that took place in the new release? Well, now you have to do the investigation again to understand the new code base and make any necessary changes again. To complicate matters, what happens in the all-too-common case of when the original developer has moved on and is no longer at the company. Now you're requiring the person(s) doing the upgrade to not only comprehend what and how the original changes were made, but to also understand how those changes are integrated into the new release (and remember, reading code is a lot more difficult than writing code).
Another hidden cost that is not often realized is a cost that younger developers are susceptible to. When developers become eager to modify source code and lean toward modifying source code as a solution to every problem, their skills as integrators are often degraded. One thing I have learned when working with Enterprise software is the rule "if it ain't broke, don't fix it". There has been a lot of time put into writing that code base and getting it to work the way it is. If the company needs to use that product with some additional functionality and you can provide the additional functionality without modifying the existing source code base, do it :). Please realize though that this is just a _general_ rule and is dependent on the context of the necessary changes.
The impact of this degradation of skill becomes more obvious when it comes to maintaining the company's current code base. I believe an important object-oriented development skill is to be able to write code that adds functionality by extension, not through modification (check out the Open-Closed Principle if you're not familiar with this concept). When your first tendency as a developer is to _modify_ the existing code to do what you need to do instead of _extending_ that same code, I believe you are doing the company an injustice as you are introducing more risk into the change. If the change you are making is similar to changes that have been made in the past, you should contemplate refactoring the code base so that the changes (and future changes along that same vector) are done through extension instead. To me, it's a sign of a mature and pragmatic developer to think along these lines. But then again, I'm still a youngin' and I'm sure some of you might disagree with me on this point.
So, is modifying OSS a "Bad Thing"? Not at all. You just have to realize that modifying the code comes with some added responsibilities. Can the company handle those added responsibilities? If your company can handle these and has the capacity to manage the upgrade path, then you can do so if necessary. Just remember though, just because you can modify the software doesn't necessarily mean you should. Are you and the company ready to pay the costs for your decision?
|